[00:06] * BUGabundo echo sleep > /etc/mode && /home/BUGabundo reload === asac_ is now known as asac === Flare183_ is now known as Flare183 === chuck_ is now known as cfmcguire === MTeck is now known as MT- === MT- is now known as MTeck === jjesse_ is now known as jjesse [04:29] Can anybody test if this is fixed in Karmic? Bug #411242 [04:29] Launchpad bug 411242 in nautilus "Links to folders on unmounted partitions pretend they are broken" [Undecided,New] https://launchpad.net/bugs/411242 [05:33] I'm told there is a critical vulnerability in JVM, however, I don't see any updates in synaptic or updated. [05:33] updater [05:50] good morning [06:02] Any bug triagers available? [06:02] dholbach, good morning [06:02] for what scream? [06:03] https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/410297 [06:03] Launchpad bug 410297 in sun-java6 "Sync sun-java6 6-15-1 (multiverse) from Debian unstable (non-free)" [Undecided,New] [06:04] I made a recommendation on the bug. [06:04] I believe it has enough information for a status change from new to triaged and since it is a remote exploit vulnerability, importance of critical. [06:05] process bugs usually are not to be touched [06:05] ok [06:06] hey scream [06:07] howdy [06:58] good morning [09:48] *blink* [12:44] *yawn* good morning bugs. === james_w` is now known as james_w [14:01] Hello, I'm using karmic and I have no sound. Anything to check before fille a bug report? [15:16] do cpan modules _ever_ get packaged? because i don't think i've ever installed a package for one. [15:16] bug 411363 [15:16] Launchpad bug 411363 in ubuntu "[needs-packaging] package Text-DHCPLeases" [Undecided,New] https://launchpad.net/bugs/411363 [15:17] me suggests apt-cache search cpan for that question [15:17] hahaha [15:17] i blame it on me being a python developer.. not a perl developer! [15:18] :) [15:21] i have a problem with busybox. when i trying to install ubuntu from dvd or cd it loses my cd-drive and fails to busybox. it started from 8.04. and i don`t know how to install ubuntu on my asus x51rl [15:21] can somebody help my&& [15:23] skazi21101, this channel is not a support channel: it deals with bugs filed in launchpad and/or upstream, and how to deal with them. You might get a better response on #ubuntu or #ubuntu+1. [15:25] people on this chanels do not hearing to me. if i could get help there i would not write here [15:41] we really have to rethink the support channel. It does not scale anymore... [15:42] hggdh: bug 392799 [15:42] Launchpad bug 392799 in ubuntu-community "#ubuntu too noisy to be useful" [Medium,Confirmed] https://launchpad.net/bugs/392799 [15:43] I disagree though.. [15:51] after confirming a needs-packaging bug, which response should be sent? a variant of the triage successful? [15:56] grepory: has a package been proposed or accepted in the repositories? [15:56] not that i could find [15:58] grepory: the AFAIK you set it to triaged, since Confirmed is when a developper submits a debdiff and subscribe sponsors to it [15:58] Pici, it is not just about being noisy, its also the amount of people there... makes it much more difficult to follow a thread [15:58] grepory: triaging a needs-packaging bug means you checked the licenses are ok or course [15:59] loic-m: i can't set to triaged as i'm not in bugcontrol. i was going by the wiki which said to set to confirmed if upstream url and license info were included in the bug. [15:59] grepory: do you have the url? [15:59] loic-m: which? [16:00] the wiki [16:00] loic-m: https://wiki.ubuntu.com/Bugs/HowToTriage#Needs Packaging Bugs [16:02] you're right... it seems to work opposite of https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue though [16:03] hahahaha [16:03] motu [16:04] grepory: just follow the wiki you linked then. I just see lots of "triaged" needs-packaging bugs, usually when a bug is "Confirmed" I won't look at it because I assume there's already a diff.gz... [16:04] loic-m: hmm.. maybe it's time i apply to bugcontrol [16:04] Well, MOTU are the ones that will usually do the packaging ;) so it's not bad to have a look at their workflow [16:05] certainly. i was just laughing at the name. i'd not heard of it before. [16:05] very clever. [16:06] grepory: "if license info and upstream url are included, set status to Traiged" on the page you've linked [16:07] loic-m: *nod* it's a little unintuitive. i think i will probably just not do the needs-packaging bugs until i'm in bugcontrol and can actually set the status to triaged. [16:07] which stinks.. because those are some of the easiest bugs ;) [16:07] I'd say look for that, add it if necessary, then set it to triaged. Unless you don't mind the package never going to be done because everybody looks at the "Confirmed" and assume the work has already been done ;) [16:07] grepory, you can always ask for a bug-controller here to set it triaged [16:08] aha! [16:08] that's a good point. [16:10] grepory, also please have a look at https://wiki.ubuntu.com/Bugs/HowToTriage#Special%20types%20of%20bugs [16:13] i believe that 411368 and 411363 can be set to triaged [16:13] hggdh: thanks [16:13] hggdh: i haven't run across any of those yet, but i'll keep an eye out. i've been trying to stick to new, unconfirmed bugs with no comments so far. [16:14] #411368 #411363 [16:15] hggdh: do you know how to contact to clarify the confusion when needs-packaging bugs are set to "Confirmed" even though there's no diff.gz attached? [16:20] bug 411368 [16:20] Launchpad bug 411368 in ubuntu "[needs-packaging] zimbra" [Undecided,Confirmed] https://launchpad.net/bugs/411368 [16:20] bug 411363 [16:20] Launchpad bug 411363 in ubuntu "[needs-packaging] package Text-DHCPLeases" [Undecided,Confirmed] https://launchpad.net/bugs/411363 [16:20] loic-m, you mean who to contact in -control? [16:22] hggdh: no, I'm talking about changing the wiki page (and convincing the bug squad team before, since I know I could just edit it) [16:22] there's no value in the confirmed stage in bug squad practice for needs-packaging bugs, and it's confusing for developpers [16:23] since they use it to mean something else on those kind of bugs [16:23] well... tell me what you need... I think if MOTU rules state a bug goes to confirmed only when a proposed package is attached (via a debdiff or diff.gz), then we can change it with no problems [16:24] you should have here a good portion of the -control folks, plus the bugmeisters [16:26] The MOTU workflow for needs-packaging bugs is detailed at https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue [16:29] loic-m, please have a look at https://wiki.ubuntu.com/Bugs/HowToTriage#Needs%20Packaging%20Bugs [16:29] is this better? [16:30] * hggdh is already convinced ;-) [16:31] I'm afraid the https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue page is going to be confusing, because it's aimed at Sponsors (not at bug triager or normal developpers) though [16:31] concur. [16:32] i don't think should be doing any of the things on this page. heh. [16:32] Wouldn't it be the same just to remove the "Confirmed" process and ask triagers to check if the homepage/license are there, and if not provide them then set it to Triaged? [16:32] loic-m, I agree. On the other hand, 'needs-packaging' triage should be limited to triagers with more experience... this is not something for people starting on triage [16:33] loic-m, and completely disregard a debdiff/diff requirement? [16:33] hggdh: from experience, new triagers tend to modify about every bug ;) [16:33] yes, I know... on one hand, I would like triagers to be able to work on all; on the other hand, there be dragons, this way [16:34] hggdh: no, going from New to Triaged means that's there's no debdiff yet. If there is a debdiff, a triager has nothing to do near that bug, since a developper is already working on it [16:34] now, *this* state jump is counter-intuitive. From new to triaged, just because the licence is there... [16:35] and to confirmed, if a diff is attached... [16:35] (and once the debdiff is uploaded, a developper unsubscribes him/herself - but since the bug is marked as 3confirmed" it should be sufficient for Triagers to understand they don't have any job left to do on that bug) [16:36] Needs Packaging bugs work a little different. Someone reports the bug. Once the bug is confirmed to be valid (and contains the correct information), it is set to confirmed/wishlist. It then stays this way until packaged [16:36] hggdh: Confirmed is set by the developper working on the needs-packaging bug anyways. To have a triager set it from Confirmed to Triaged "because the bug wiki says so" is upsetting [16:36] yes, I understand. I just think this sounds like an abuse of the stati. It does work, though. I really wish LP would get the workflow thingies intetrated [16:36] The normal sponsorship process does not apply [16:36] nhandler, I know. I just dislike the overload ;-) [16:37] nhandler: I would agree, but in practice going from Confirmed to Triaged in the bug squad workflow means that some triaged come during the sponsorship process [16:37] Really, the one important piece about triaging the needs-packaging bugs is ensuring the title is in the proper format and that it is tagged needs-packaging. That ensures that people interested in packaging that application can find the bug [16:37] OK. So let's get back. Would you like jus pointing to the MOTU page, and stating that these workflow bugs should only be changed by experienced triagers/MOTUs/whatever? [16:38] hggdh: For the most part, there is no real need to triage workflow bugs [16:38] nhandler: you say "Once the bug is confirmed to be valid (and contains the correct information), it is set to confirmed/wishlist. It then stays this way until packaged", but that's for the status "Triaged" in bug squad workflow [16:39] loic-m: For most workflow bugs, you will find that triaged is not used much [16:39] loic-m, indeed. But these are not really bugs, they are packaging requests. [16:39] In the bug squad wiki page, the stage "Confirmed" for needs-packaging bugs doesn't add much - by adding the license and the homepage, a "Confirmed bug" would go from confirmed to triaged [16:39] and this is the crux: they look, smell, taste, and feel like "normal" bugs, but are not [16:40] nhandler: I'm talking about the bug triagers workflow, which is to go from Confirmed to Triaged for n-p bugs [16:41] loic-m: To be honest, I see no benefit in that. The n-p bugs shouldn't be marked confirmed until they have the required information [16:41] This might make a good topic for a Packaging Training session [16:41] nhandler: see the bug triaging workflow on n-p bugs up to now: "if not in Debian or Ubuntu, then set the status to Confirmed, the importance to Wishlist (if possible), and add the tag needs-packaging if absent.if license info and upstream url are included, set status to Traiged" [16:41] what about: check for the licences, check for an already opened request for packaging, here and at Debian, check for the 'needs-packaging' title & tag. Do *not* change status [16:42] hggdh: they could actually set it (or ask someone to set it) to Triaged without harm [16:42] bdmurray, and I were discussing this some days ago (and, by pinging, I hope he joins the discussion) [16:43] I can see we have some confusing documentation on triaging these work flow bugs. I'll talk to some people and see if we can get a packaging training session done about them and/or get some clear and accurate documentation on the wiki [16:43] hggdh: the problem isn't in the Triaged tag - it's in the tag "Confirmed" that the bug wiki said had to be set if a package isn't in U/D, but there's no info for License/homepage yet [16:44] OK. one more version: (1) check & add the licences types; (2) check for an already opened packaging request at LP or b.d.o; (3) check & add 'needs-packaging' in the description & tag; all steps being successful, mark (or ask for) as triaged [16:45] nhandler: I find the "Triaged" tag usefull when looking at n-p bugs, since it means the program isn't in U/D, and the license allows packaging it. The trouble was the "Confirmed" tag, see previous rev athttps://wiki.ubuntu.com/Bugs/HowToTriage?action=recall&rev=98#Needs%20Packaging%20Bugs [16:45] nhandler, this would be marvelous. Targetting the triagers would be even better (although *all* should understand the flow) [16:45] hggdh: that is very clear and understandable and appears to be concordance with motu workflow. [16:46] concordant. [16:46] hggdh: that looks good. Especially the part about checking if there's an ITP in Debian, and duplicates in LP [16:46] grepory, I *think* so, also. But I would rather have either nhandler or loic-m agreeing [16:46] hggdh: certainly, just offering from the "i have no idea how all of this works" perspective. [16:47] loic-m, nhandler, I will change so, and ask for validation from you. I will also send an email to -bugs about it. Should I also copy -motus? [16:47] hggdh: my main concern is having triagers set n-p bugs as Confirmed. Then, it's true having triagers look for relevant info and adding it makes the tag "Triaged" worthwile [16:47] grepory, :-) [16:47] hggdh: I think -bugs would be fine [16:47] I will try and organize a session about this sometime this month (depending on who I find to lead it) [16:48] loic-m, my concern, also. With all due respect, what I do not like is the flip of triaged/confirmed -- it is absolutely not coherent with standard bug flow. But such is life. [16:48] hggdh: your proposal sounds great. Just the part about checking for b.d.o, what is that? [16:48] bugs.debian.org [16:50] hggdh: thanks, so I understood correctly. For b.d.o, maybe it would be good to specify that an ITP open in Debian would not prevent the bug to be set as Triaged [16:50] Just that the triager makes sure the ITP on b.d.o is linked to [16:51] loic-m, will do. I will ping you as soon as the new version of the page is ready [16:51] hggdh: thanks a lot [16:51] my pleasure :-) [16:54] thanks for the clarification! :) *gently sets n-p bugs aside for now* === dholbach_ is now known as dholbach [17:20] * hggdh is right now busy with a customer. Will get the new page soon ASAP [18:31] brb [18:35] loic-m, nhandler, please look at https://wiki.ubuntu.com/Bugs/HowToTriage, and correct me where needed [19:23] hddgh: what should i do with bugs 411363 and 411368? they are marked confirmed now, as per previous version of the wiki's instructions, but i think they meet the requirements to be packaged. would you mind taking a look at them and marking them as triaged or advising? thanks! [19:23] Launchpad bug 411363 in ubuntu "[needs-packaging] package Text-DHCPLeases" [Undecided,Confirmed] https://launchpad.net/bugs/411363 [19:23] Launchpad bug 411368 in ubuntu "[needs-packaging] zimbra" [Undecided,Confirmed] https://launchpad.net/bugs/411368 [19:35] hddgh: just looked at the wiki edit, looks fine, thanks! [19:35] loic-m: Do I understand things correctly that a bug would move from New -> Triaged -> Confirmed? [19:36] for triagers, no. A needs-packaging bug would only go from New to Triaged [19:37] loic-m: I was asking about "a bug" not triagers [19:37] Confirmed occurs when a developpers has worked on a bug, and when he/she has started working on the bug (In progress, assigned) bug triagers don't have anything to do on these bugs [19:38] bdmurray: for triagers: new>triagged; then developpers: triagged>in progress>confirmed>Fix Commited>Fix Released [19:39] "Confirmed" status is used during the dev workflow for bugs where they upload a diff.gz [19:39] That's part of the sponsorship workflow, AFAIR everybody understands it's not the best use of the tag, but it's in the "policy" for devs [19:40] bbl sorry [19:40] I'm not certain where this work flow comes from but think that the _status_ triaged makes a lot more sense [19:40] I think that policy was written before triaged existed and it should change [19:41] additionally there shouldn't be different bug life cycles if one happens to a developer or a triager as that overly complicates things and makes it harder for people to participate [20:01] I agree. the flow new->triaged->confirmed makes no sense, and it is bound to make things much more confusing [20:03] even with the overload from bugs to workflow, some basic schema should remain the same [20:03] grepory, will look at them now, thanks for working on them, and your patience [20:05] grepory, did you check debian for an already-existing ITP? [20:06] boas [20:11] boas, BUGabundo [20:11] ola carlos [20:34] bdmurray, hggdh: the "Confirmed" tag is indeed not optimal during Sponsorship [20:35] however, the process up now was for n-p bugs: new>confirmed>triaged>confirmed>Fix [20:36] Which in reality was more like new>confirmed>triaged>confirmed>triaged(thanks to bug triager...)>long discussion, banging head on the wall>Confirmed>>Fix [20:36] loic-m: its not a tag but a bug status, additionally I'm not sure where or why the Confirmed status is being used during sponsorship but don't think it should be [20:36] bdmurray: it is for n-p bugs [20:37] loic-m: and where does this process come from? [20:37] bdmurray: that's another matter, but until Sponsorship or LP comes with a better status (sorry, I used tag for convenience)... [20:38] The sponsorship process at https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue [20:38] loic-m: I think Triaged makes much more sense for the sponsorship process. Additionaly, I thought sponsorship really only happened if the right team was subscribed to the bug report so the status isn't really the important bit [20:38] "The Status should be "Confirmed" for bugs that represent a new candidate revision" [20:39] loic-m: I don't think that documentation has really been updated since the Triaged bug state has come out and think Triaged is a more appropriate state for the sponsorship process if one were required [20:40] bdmurray: I'm not sure for Triagged - the meaning makes less sense than Confirmed, even though in the order of things for bugs triaggers it might look awkward [20:40] loic-m: Could you elaborate as to how you think it makes less sense? [20:40] bdmurray: Doesn't triagged mean there's enough data for a dev to come in though? [20:41] ^^ [20:41] loic-m: Yes and confirmed means another report has experienced the same bug [20:42] And it's not like it will disrupt bug triaggers workflow, since they shoudn't in any event set the bug to Confirmed for n-p when the diff.gz is attached [20:43] But feel free to discuss that with the dev team. Last that was discussed, people agreed it wasn't stellar, but was better than the other tags (that was a few month ago) [20:43] Triaged is also likely a better state for the sponsorship process since only certain people can set it in Launchpad for Ubuntu bug reports [20:43] No, devs can't set it to triagged, and comming to #u-b during the sponsorship process wuold be less than stellar [20:44] I'm not sure what you mean by devs, but both the core dev team and motu teams are part of the bug control tream [20:44] bdmurray: Triagged doesn't correspond to the state of bugs requiring sponsorship. [20:45] bdmurray: not packager is an "official dev", that's why there's the sponsorship process [20:45] bdmurray: the ones that are motu/core dev don't need sponsorship, so it wouldn't make sense [20:46] also, a dev (non motu or core) shouldn't have to fire IRC for just dealing with the bug [20:46] loic-m: okay, but if a member of bug control set a n-p bug to triaged, a developer would need to do nothing other than add the diff.gz and subscribe the appropriate team [20:47] even though it can be nice, I'm not sure everybody will be happy to require everyone in sponsorship proces for a bug to track somebody on IRC - then the sponsorship process for uploads on LP would be moot, since you'd just go and track somebody on IRC [20:48] bdmurray: I can't do anything about the Sponsorship policy, I'm just stating what it is right now [20:50] bdmurray: also, the bug squad wiki page revision 2 hours ago showed little point to go from New>Confirmed>Triaged, since the amount of work a triager had to do to set a n-p bug to Confirmed didn't add much to a bug report - while the Triaged requirements were already more justified of a bug triager intervention [20:52] Amount of effort/results was not in favor of the Confirmed stage for n-p bugs, and conflicted with the _present_ sponsorship process (not the "ideal" or "possible" one) [20:52] Like I said, 2 hours ago it lead to this kind of process: new>confirmed>triaged>confirmed>triaged(thanks to bug triager...)>long discussion, banging head on the wall>Confirmed>>Fix === jdstrand1 is now known as jdstrand [20:54] Since bugs triagers looked at a n-p bug during sponsorship, saw it at "Confirmed", and set it back to "Triaged", even though a dev had already done the job and was waiting for a sponsor (which can take a while) [20:55] And again I think the most appropriate thing to do is to modify the sponsorship process to allow either confirmed or triaged bugs to be sponsored but I'll bring that up on the mailing list [20:56] bdmurray: ok, thanks [20:57] bdmurray: also note the Confirmed status is also used for merges with Debian bugs, and merges from upstream. [20:59] bdmurray: other bugs, we set the status to New for the Sponsorship process. Which is also confusing for overzealous bug triagers [21:01] bdmurray: my problem with Triaged is that it would be a pain for devs - when you look for bugs to work on, Triaged means nobody has cared for the bug [21:03] loic-m: How does Triaged me "nobody has cared for the bug"? [21:04] bdmurray: when a dev is already on a bug, the bug is In Progress. I guess I just got used to look for Triaged bugs to work on, maybe I'm wrong [21:05] and n-p bugs up now with "Confirmed" meant the bug was only waiting for Sponsorship, so I didn't have to look into those bugs [21:06] OK. Going back a bit, then, it seems we could indeed use the accepted FSM, with a change in interpretation from MOTU [21:10] Indeed. As long as there's no conflict b/w the policies. Then we can pester Launchpad to add a more relevant status for the Sponsorship process... === e-jat is now known as Guest24062 === ejat is now known as e-jat === nixternal_ is now known as nixternal [21:14] loic-m, this has been under my radar for some years, now... [21:18] hggdh: a new status? [21:20] loic-m, a new class of LP entries, different from bugs. [21:20] perhaps modelled after bugs, but *not* bugs [21:21] hggdh: usefull indeed, but how will that help the sponsorship process or dev workflow in general? [21:22] it will not be confused with a bug, with all the issues we have every so often, with triagers getting confused. It should also provide the packagers/developers with a cleaner view of what they have to do [21:24] but how does it affect the workflow when a bug is reported, then a diff.gz is submitted? [21:25] unless there's a way to convert a bug to the new class of LP entry (and maybe back if there's a mistake)? [21:29] this would have to be considered. The problem I see right now is we only have the bug class in LP, so everything is a bug. A direct consequence is the confusion between a real bug and, for example, a n-p [21:29] so, instead, we could, for example, have a major class from which bug and (say) n-p are extended [21:30] what does n-p stand for? [21:30] needs-packaging [21:31] needs-packagin [21:31] g [21:31] (loic was faster) [21:31] it's just that we've been talking about that for a while, it's not an official abreviation AFAIK [21:31] ;) [21:32] but if we overload bugs to also include n-p, then this class should conform with the generic 'bugs' class, otherwise things will get extremely confusing for all [21:32] The new class could work for n-p and merges, but only as long as users get used to it - so there'll have to be a way to convert bugs [21:33] It doesn't solves the sponsorship problem for all bugs though, while a new status (or a better consensus on status) would [21:33] oh yes, no doubt. But, given our current 6-month schedule, this would be quite a short period. Still, it has to be kept in mind [21:34] At the moment, status can't be really used to determine the status of the bug - since one has to open the page and read the bug (can be long) to determine its status [21:34] changing the stati is another battle ;-) I would personally not like extending the status FSM to cover for other issues that are not bugs. it might be easier to add another identifier, at the same level (for example), which would take values [21:35] like 'bug', or 'workflow', or 'sync/merge', etc [21:35] I don't know how to best do it, but at the moment the status is made pointless for bugs - it doesn't inform like it should, because the same status is used for 2 different things [21:36] loic-m, I agree. Its one of the costs we incur when (ab)using bugs to mean other things [21:36] there you go. *THIS* is my issue [21:37] What do you mean by "other things"? Do you think the sponsorship process shouldn't be done inside the bug one requires sponsorship for? [21:40] If a bug is in a state where it only needs a sponsor, isn't that a relevant information for the Status field? New, Triagged or Confirmed don't represent the sate of the bug at that time [21:40] And it's not In Progress, because the dev has finished his work [21:40] no, that's not what I meant. My basic gripe is on using a BUG -- a problem report -- to mean something completely different from problem. For example, sync, merges, and n-p's [21:41] and you are looking at the 'bug' only from the eyes of a packager/maintainer/developer [21:41] hggdh: right, I agree they're not the same as bugs [21:42] hggdh: but even though you new class sounds right, there will still be "real" bugs, that will also require a sponsorship process [21:43] this is the problem, Loic. We are abusing the concept of a bug. This generates confusion, since a bug is a bug is a bug. [21:43] (unless Ubuntu had thousands of MOTU ;) ) [21:43] heh. Easier that getting thousands of triagers ;-) [21:44] this all has to be carefully considered. For example, a workflow could be implemented as a task under a (sigh) bug. [21:44] :} [21:44] * hggdh still does not like it, but ah well. ça va [21:45] Yes, but what is the meanning of marking a bug as triagged when somebody is working on it, or when it's just awaiting sponsorship? [21:47] If there's no status for the bug during the weeks/month where a patch or a diff.gz is waiting for a sponsor, it ends up with status that are "wrong" because they describe a different state than that of the bug [21:48] hi everyone [21:49] welcome to my nightmare... [21:49] why does that matter so much to you? [21:50] open bugs with with sponsor team subscribed are waiting for sponsoring [21:50] ease of usage, and understanding... and trying to take new triagers from causing issues [21:51] but. Ah well. [21:51] well just mark bugs confirmed and subscribe sponsors [21:52] seb128: the pôint is that you have to read the page of the bug to know its status, thus making the status field irrelevant [21:52] and with LP speed, that's a big drawback [21:53] especially if you're on a low-end computer [21:53] well the status is clear [21:53] it's new, confirmed, triaged, in progress = open [21:53] it's incomplete or wontfix or invalid = closed [21:53] seb128: no, the status can be New or Confirmed, even though it's past the In progress stage and is just waiting for a sponsor [21:54] how does it matter, it's open and on the sponsoring list [21:54] seb128: so you mean only 2 status can be infered with 7 different status? [21:54] I'm just speaking about sponsoring [21:54] that's less than stellar - why not just open/closed ;) ? [21:54] basically things are on http://people.ubuntu.com/~dholbach/sponsoring/index.html or not [21:55] because there is not only sponsoring bugs? [21:55] seb128: not everybody is a sponsor, and LP is also useful to other ppl [21:55] I fail to see the issue there [21:55] You might have missed the discussion [21:55] just ignore sponsoring bugs if you don't know how those work [21:55] I do [21:55] or muy sentence above in answer to one of you comments [21:56] [22:52] seb128: the pôint is that you have to read the page of the bug to know its status, thus making the status field irrelevant [21:56] [22:53] seb128: no, the status can be New or Confirmed, even though it's past the In progress stage and is just waiting for a sponsor [21:57] When a bug is in the sponsorship phase (which can take a while), it appears as a New bug, or as a Confirmed bug - both cases where one would expect some work needs to be done on the bug [21:58] loic-m, set it triaged then [21:58] I fail to see how one would not expect some work needs to be done on the bug if it's marked to triaged [21:59] In the end, the status field value is void, because one has to open the bug page and scan through it to check the real state of the bug [22:00] ? [22:00] "triaged" means "let the maintainer to their work" [22:01] Some people might not see the point of a Status field, but if it's there on LP (and about every BTS out there), it's because it provides relevant information [22:01] which is "upload the change" for those bugs [22:01] you seem to be the one failing to understand status [22:01] seb128: there's no "maintainer" in Ubuntu [22:01] so who upload the packages used there? [22:01] seb128: no, triaged is used differently since it's set by bug triagers (who aren't maintainers) [22:02] "triaged" means "let the maintainer to their work" [22:03] right [22:03] it means "doesn't need to be triaged" [22:03] ie if you are a bug triager ignore it [22:03] ^^ that would work perfectly if there was only one maintainer / package [22:03] if you work on the page look at it [22:03] we have no issue using that on hundred of desktop packages [22:03] seb128: you're only considered that from the eyes of a triager [22:03] no, I'm not a triager I'm a maintainer [22:03] s/considered/considering [22:03] or I'm both rather [22:04] when I want to triager I look at new and confirmed bugs [22:04] when I want to do an upload or work on a package I look at triaged ones [22:05] you say "when I want to triager I look at new and confirmed bugs". However, bugs awaiting for a sponsor don't need to be triaged (there's already a dev that is caring for the bug) [22:06] Thus, without looking at the bug, you have no way to see if a News or Confirmed bug needs to be triaged [22:06] ? [22:06] And as a packager/dev, it's the same [22:06] set the bug to triaged when you wait for review [22:07] seb128: bugs with patches and awaiting for a sponsor have the status reverted to New [22:07] by who? [22:07] seb128: that's the sponsorship process [22:07] https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue [22:07] motu keep doing weird things [22:08] I feel I'm spending the evenning writting the same things over and again [22:08] yeah, don't bother I should not comment there [22:08] which is not my idea of a productive evenning, even less an enjoyable one facepalm [22:08] it seems motu has lot of weird rules we don't use for desktop packages [22:09] And "triaged" would give the same troubles if used during sponsorship [22:10] I shouldn't have to re-explain it for the 10th time, but if so just replace new and confirmed by "triaged" on my previous sentences [22:11] seb128: what do you use for -desktop packages? [22:11] we don't set bugs waiting for sponsoring to new [22:12] what state are they in that indicate they're in sponsorship wait then? [22:13] we query for bugs were the sponsor team is subscribed [22:13] any bug open with sponsors subscribed is waiting for sponsoring [22:14] seb128: yes, but doesn it work when a dev (non-sponsor) is looking for bugs to work on? What indicates to him in the status that the bug has been worked on? [22:15] seb128: you only see subscribers when you read the bug page [22:15] by that times it only shows the bug status wasn't conveying meaningful information [22:16] well you can add as many status as you want you will not carry all informations there [22:16] is if the bugs is revelant to translators, sponsors, stable team, etc [22:17] seb128: the bug title is usually enough to determine who can work on it [22:17] there is a reason why bugs have comments and description [22:17] status is another meaning [22:17] seb128: what you're saying is that status doesn't carry information on the _status_ of the bug, since one has to read the bug page to check its status [22:18] I agree comments and description are essential, but Status is a field that has a purpose - which just happens not to work so much with Ubuntu's workflow combined with the Status available [22:19] the status are not different from the ones in other bug trackers [22:20] there is just a limit of what you can carry in a status value [22:21] seb128: the difference is that there's no ownership of packages in Ubuntu, and Ubuntu is also far more understaffed than any other project [22:22] not really true [22:22] the status right now works ok in Debian f.e., with thousands of devs and less bugs reported at a time [22:22] what difference does it make if a component is owned by a team or an invididual? [22:23] Ubuntu has a a number of MOTU/Core devs in the double digits, and far more bugs, which means it needs "outside" contributors to cope with the workload [22:23] Thus it needs a sponsorship process for a really big number of bugs [22:24] The bugs where a MOTU uploads a fix don't need sponsorship, but MOTU aren't enough to upload all the fixes and package everything, merges, etc... [22:25] we have a sponsorship process [22:25] http://people.ubuntu.com/~dholbach/sponsoring/index.html [22:25] anything on this list is to sponsor [22:25] I'm not sure you understood - you're still looking at it from the eyes of the sponsor [22:26] Not from the eyes of a non-MOTU/non-Dev [22:26] which is what matters [22:26] No, not to most people using LP [22:26] users who need sponsoring just need to subscribe the sponsor team [22:26] there is only 2 class of users who matters there [22:26] the one who do the work and the one who review it [22:26] everybody else is out of this workflow anyway [22:26] I'll copy paste one more time [22:26] one sec [22:27] [23:14] seb128: yes, but doesn it work when a dev (non-sponsor) is looking for bugs to work on? What indicates to him in the status that the bug has been worked on? [22:27] [23:05] you say "when I want to triager I look at new and confirmed bugs". However, bugs awaiting for a sponsor don't need to be triaged (there's already a dev that is caring for the bug) [22:27] [22:59] In the end, the status field value is void, because one has to open the bug page and scan through it to check the real state of the bug [22:28] [22:56] [22:52] seb128: the pôint is that you have to read the page of the bug to know its status, thus making the status field irrelevant [22:28] your issue is that triagers will open some sponsoring request just to notice they don't need triaging? [22:28] that, and devs will open sponsoring request just to notice they don't need work to be done on [22:29] well then define a convention using the title [22:29] and triagers will change bug status back and forth too [22:29] that's orthogonal to maintainer number though [22:29] debian will have the same issue [22:29] Please explain [22:29] if you decide to go clean the debian bts on something you will have to open bugs too [22:29] explain what? [22:30] get motu to change the sponsoring process to have "[sponsoring] in the title" [22:30] so those can be ignored from the bug list [22:30] if you think that's so much of an issue [22:30] So we're going to use the title to show the status of a bug? [22:31] no, to show that class of the bug [22:31] ie that the bug is a sponsoring one [22:31] so only revelant to sponsors [22:31] no status will achieve what you want [22:31] It's not a class, since a bug like "XXX segfault on startup" isn't a "sponsorship" bug [22:32] well from the moment it has a patch to review it's one [22:32] if it's not waiting for review status is revelant [22:32] That's the status of the bug you're describing, not its class [22:33] let's stop that this discussion and say we disagree on bug use ;-) [22:33] Does a bug changes "class" back and forth? [22:33] yes [22:33] if there is nothing waiting for sponsoring it's not a sponsoring request [22:33] if there a patch it's a sponsoring request [22:33] So a segfault bug becomes a sponsorship one, and back to a segfault one if the patch isn't accepted? [22:33] yes [22:34] the status doesn't change [22:34] a crash bug triager has all infos [22:34] triaged [22:34] changing status while fixes are suggested would be wrong [22:34] so you need something else than the status to set that info [22:34] Why is a bug someone is working on a status info, while a bug sponsors need to work on a class info? [22:35] [23:34] changing status while fixes are suggested would be wrong > yet it is the workflow at the moment [22:35] I don't say the current workflow is perfect [22:35] but your issue can't be solved with status information [22:35]