From jhansonxi at gmail.com Sun Jun 1 03:43:33 2008 From: jhansonxi at gmail.com (Jeff Hanson) Date: Sat, 31 May 2008 23:43:33 -0400 Subject: Suggestion for canned response for "Packages not provided by Ubuntu" Message-ID: https://wiki.ubuntu.com/Bugs/Responses acroread bug #236219 was marked invalid for Hardy. The reason was confusing as the package is in Launchpad. I quickly figured out it was because it was in Dapper but is no longer supported by Ubuntu in current releases. The response should indicate this otherwise beginners are going to be confused/annoyed. I was going to add it to the Wiki but decided it was better to let the bug squad members figure it out. From wolfger at gmail.com Sun Jun 1 10:46:11 2008 From: wolfger at gmail.com (Wolfger) Date: Sun, 1 Jun 2008 06:46:11 -0400 Subject: Changes to the triage guide - translation bugs In-Reply-To: <4841B0A0.8050003@ubuntu.com> References: <1212249504.6100.77.camel@riemann> <4841B0A0.8050003@ubuntu.com> Message-ID: <3b00b3330806010346n4e4a5d10wbdc5a66d3a070fa@mail.gmail.com> I would have to agree. A bug is a bug, whether it be in the code or in a translation. If we could write a clear process for assigning the bug to a translation team, that would be great. Unfortunately, it doesn't look so clear. I went to "Subscribe someone else" on a bug and searched on "translation" and got a huge list of teams. Some are language-specific (danish-translators), some are package specific (clipperz.translators), some are specific to a particular language and package combination (clipperz.italian), and some give no clue as to what they are about (dwayne-translate). On Sat, May 31, 2008 at 4:10 PM, Og Maciel wrote: > I'd like to second Susana's suggestion! > > Cheers, > -- > Og B. Maciel > > omaciel at foresightlinux.org > ogmaciel at gnome.org > ogmaciel at ubuntu.com > > GPG Keys: D5CFC202 > > http://www.ogmaciel.com (en_US) > http://blog.ogmaciel.com (pt_BR) > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > -- Wolfger http://wolfger.wordpress.com/ My 5 today: #120764 (gutenprint), #110599 (alsa-driver, linux, linux-source-2.6.20), #192067 (adept), #177805 (scribus), #105754 (debian-installer) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day From pascal.devuyst at gmail.com Sun Jun 1 14:57:31 2008 From: pascal.devuyst at gmail.com (Pascal De Vuyst) Date: Sun, 1 Jun 2008 16:57:31 +0200 Subject: Changes to the triage guide - translation bugs In-Reply-To: <1212249504.6100.77.camel@riemann> References: <1212249504.6100.77.camel@riemann> Message-ID: Hello Susana, I fully agree that translation bugs shouldn't be closed as invalid and we should have a better triaging workflow. Based on my experience I currently triage translations bugs using the following workflow: 1) Check if the application with the translation bug is in main or universe on packages.ubuntu.com [1], packages in universe have an indication [universe] behind them. 2a) For applications in main change package to either language-pack-, language-pack-gnome- or language-pack-kde- (where is the language code and optional country specific suffix). At doubt between these 3 packages check on packages.ubuntu.com [2] to see which of these packages contains the applications .mo file. Then I assign the bug to the ubuntu-l10n- team. 2b) Translations bugs for applications in universe should be set to their respective applications package since we don't have language packs for universe yet [3]. They should also be forwarded upstream as described here [4]. Any improvements/suggestions/comments to this workflow are welcome. We should agree on a workflow for translations bugs and add it to the Bugs/HowToTriage wiki page [5]. The response for closing translation bugs as invalid should be removed from the Bugs/Responses wiki page [6]. [1] http://packages.ubuntu.com/ [2] http://packages.ubuntu.com/language-pack- http://packages.ubuntu.com/language-pack-gnome- http://packages.ubuntu.com/language-pack-kde- [3] https://launchpad.net/ubuntu/+spec/language-packs-for-universe [4] https://wiki.ubuntu.com/Bugs/HowToTriage#head-ab0eb9d7731fa877b5fc866eedc4c312dab50ee7 [5] https://wiki.ubuntu.com/Bugs/HowToTriage [6] https://wiki.ubuntu.com/Bugs/Responses > As I understand it, there is no meta package that reporters can report > their translation bugs to and translators can subscribe to without the > need of bugsquad work. This would decrease work for triagers that > already have too much work, and would make fixing these issues faster. We could create a launchpad project for this but I don't think this will reduce work for triagers since this would still require bug reporters to know to report bugs to this project. Most reporters report translations bugs against the respective applications package or no package at all. > But if this is not possible, translators could perhaps be encouraged to > subscribe their relevant language packages (e.g. language-pack-*, > language-support-*) and when bugs are reported against the application > itself triagers would subscribe the team or change package. It is always a good idea to let people/teams subscribe to bug mail of ubuntu packages or projects of their interest, ubuntu-l10n- teams should subscribe to bug mail of [7]. [7] https://launchpad.net/ubuntu/+source/language-pack-/+subscribe https://launchpad.net/ubuntu/+source/language-pack-gnome-/+subscribe https://launchpad.net/ubuntu/+source/language-pack-kde-/+subscribe https://launchpad.net/ubuntu/+source/language-pack--base/+subscribe https://launchpad.net/ubuntu/+source/language-pack-gnome--base/+subscribe https://launchpad.net/ubuntu/+source/language-pack-kde--base/+subscribe Kind regards, Pascal From susana.pereira at gmail.com Sun Jun 1 15:01:48 2008 From: susana.pereira at gmail.com (Susana Pereira) Date: Sun, 01 Jun 2008 16:01:48 +0100 Subject: Changes to the triage guide - translation bugs In-Reply-To: <3b00b3330806010346n4e4a5d10wbdc5a66d3a070fa@mail.gmail.com> References: <1212249504.6100.77.camel@riemann> <4841B0A0.8050003@ubuntu.com> <3b00b3330806010346n4e4a5d10wbdc5a66d3a070fa@mail.gmail.com> Message-ID: <1212332508.8281.46.camel@riemann> Hi Wolfger, Thanks for your input. I agree that for people not used to translations this can look confusing. Let me see if I can help make it more clear. Dom, 2008-06-01 às 06:46 -0400, Wolfger escreveu: (...) > Unfortunately, it doesn't > look so clear. I went to "Subscribe someone else" on a bug and > searched on "translation" and got a huge list of teams. Official Ubuntu Translation teams names follow this syntax: "ubuntu-l10n-XX" where XX is the language ISO 639-1 or 639-2 code and can have more than 2 letters. They are responsible for translating most packages from the main repository (descriptions aside). You can see the full list of teams here: https://translations.edge.launchpad.net/+groups/ubuntu-translators > Some are > language-specific (danish-translators), some are package specific > (clipperz.translators), some are specific to a particular language and > package combination (clipperz.italian), and some give no clue as to > what they are about (dwayne-translate). These are not Ubuntu translators teams. I can't find clipperz in Ubuntu, it appears to be an online project. The bugsquad page says: "The Bug Squad is the first point of contact for the bugs filed about Ubuntu.", so it appears to me that general projects registered in Launchpad go beyond its scope, but I'm not a bugsquad member so I don't really know. I understand that searching for translators in launchpad is not helpful here, but I hope the link I gave above is better. In any case, not knowing what to do to a report is not, imho, a valid reason to close it. When in doubt asking for help or moving on to a different report is better. Regarding reports about translations in packages not in main I still think that subscribing the Ubuntu translators team is a better option. They may not be directly responsible for that translation but they should know who to contact about it. Cheers, Susana > > On Sat, May 31, 2008 at 4:10 PM, Og Maciel wrote: > > I'd like to second Susana's suggestion! > > > > Cheers, > > -- > > Og B. Maciel > > > > omaciel at foresightlinux.org > > ogmaciel at gnome.org > > ogmaciel at ubuntu.com > > > > GPG Keys: D5CFC202 > > > > http://www.ogmaciel.com (en_US) > > http://blog.ogmaciel.com (pt_BR) > > > > -- > > Ubuntu-bugsquad mailing list > > Ubuntu-bugsquad at lists.ubuntu.com > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > > > > From kiko at canonical.com Sun Jun 1 23:17:51 2008 From: kiko at canonical.com (Christian Robottom Reis) Date: Sun, 1 Jun 2008 20:17:51 -0300 Subject: Proposed changes to workflow bug management Message-ID: <20080601231751.GE6087@async.com.br> > I still think it's useful to have this feature. I don't see why > assigning a bug to a team as part of workflow is so difficult to > understand as a concept. Well, you have a use case which implies it's useful, but that view is at odds with that assignment means in Launchpad -- and in fact, to most people that look at such bugs. It doesn't actually mean anything to assign a task to a team, in the strict sense of assignment that Launchpad implies. There is nobody responsible for it, and in fact, bugs can linger in the assigned state before anybody has actually set it to Triaged (meaning it might not even be a bug) and also well after that. Users get confused with the assignee being set when in fact nobody is actually committed to fixing that bug. It's unclear who to talk to to get information on progress. I get the feeling that team assignment is used to produce a list of bugs to work off from. I also think it's used mainly because of shortcomings in the bug tags feature. If you tagged x86 bugs with an x86 tag and it stuck, it would have the same effect of putting a bug on a list that could then be looked at by a separate team -- all you'd need to do is update bookmarks. -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3376 0125 From wolfger at gmail.com Mon Jun 2 09:20:30 2008 From: wolfger at gmail.com (Wolfger) Date: Mon, 2 Jun 2008 05:20:30 -0400 Subject: Changes to the triage guide - translation bugs In-Reply-To: <1212332508.8281.46.camel@riemann> References: <1212249504.6100.77.camel@riemann> <4841B0A0.8050003@ubuntu.com> <3b00b3330806010346n4e4a5d10wbdc5a66d3a070fa@mail.gmail.com> <1212332508.8281.46.camel@riemann> Message-ID: <3b00b3330806020220s1bcec0e8uaa7744e5dd8f0d7b@mail.gmail.com> On Sun, Jun 1, 2008 at 11:01 AM, Susana Pereira wrote: > Hi Wolfger, Hi Susana. :-) > Thanks for your input. I agree that for people not used to translations > this can look confusing. Let me see if I can help make it more clear. > > Official Ubuntu Translation teams names follow this syntax: > "ubuntu-l10n-XX" where XX is the language ISO 639-1 or 639-2 code and > can have more than 2 letters. Thanks for clearing that up. That should be pretty easy to document, and for people unfamiliar with translations to understand. > I understand that searching for translators in launchpad is not helpful > here, but I hope the link I gave above is better. In any case, not > knowing what to do to a report is not, imho, a valid reason to close it. > When in doubt asking for help or moving on to a different report is > better. Oh, I agree. I don't think (once we stop telling triagers to close translation bugs) many people will close bugs they don't know what to do with, but if we can't make it clear who to assign to a bug you will likely end up with some well-meaning triagers assigning bugs where they don't necessarily belong. Sounds like this can be adequately documented, though, so we can educate our triagers. > Regarding reports about translations in packages not in main I still > think that subscribing the Ubuntu translators team is a better option. > They may not be directly responsible for that translation but they > should know who to contact about it. This sounds good to me. -- Wolfger http://wolfger.wordpress.com/ My 5 today: #126074 (xserver-xorg-video-openchrome), #36923 (xorg), #15178 (linux-restricted-modules-2.6.15), #102443 (clamtk), #177951 (update-manager) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day From ben.collins at canonical.com Mon Jun 2 12:53:35 2008 From: ben.collins at canonical.com (Ben Collins) Date: Mon, 02 Jun 2008 08:53:35 -0400 Subject: Proposed changes to workflow bug management In-Reply-To: <20080601231751.GE6087@async.com.br> References: <20080601231751.GE6087@async.com.br> Message-ID: <1212411215.8011.239.camel@cunning> On Sun, 2008-06-01 at 20:17 -0300, Christian Robottom Reis wrote: > > I still think it's useful to have this feature. I don't see why > > assigning a bug to a team as part of workflow is so difficult to > > understand as a concept. > > Well, you have a use case which implies it's useful, but that view is at > odds with that assignment means in Launchpad -- and in fact, to most > people that look at such bugs. > > It doesn't actually mean anything to assign a task to a team, in the > strict sense of assignment that Launchpad implies. There is nobody > responsible for it, and in fact, bugs can linger in the assigned state > before anybody has actually set it to Triaged (meaning it might not even > be a bug) and also well after that. Users get confused with the assignee > being set when in fact nobody is actually committed to fixing that bug. > It's unclear who to talk to to get information on progress. I don't see that as being true. First off, it's not assigned to the team until it is triaged and secondly, before it is triaged, it can be assigned to the triager. Also, when it is assigned to a team, the entire team is responsible for bringing it to the next step, and contacting the team is as easy as contacting a single person (thanks to launchpad :). So I understand the problem you have with the feature itself, but the way we use it isn't depending on the problems themselves. > I get the feeling that team assignment is used to produce a list of bugs > to work off from. I also think it's used mainly because of shortcomings > in the bug tags feature. If you tagged x86 bugs with an x86 tag and it > stuck, it would have the same effect of putting a bug on a list that > could then be looked at by a separate team -- all you'd need to do is > update bookmarks. Having a list of bugs to work from is the loose sense of the reason it is being used. The real use is to be able to separate responsibilities within a single package. A large package such as the linux kernel cannot have a single point of responsibility, and thus, not a single point to assign it to, unless we can break it down into teams. This is moot for intrepid and beyond, but I can see this being a reoccurring use case, so it might as well get resolved. I believe I've stated to the LP team once or twice in the past, that being able to control the tags associated to a particular package would make this easy to do without assigning to a team (would also make tags much more useful), but something with more visibility would be best. From kiko at canonical.com Mon Jun 2 15:17:19 2008 From: kiko at canonical.com (Christian Robottom Reis) Date: Mon, 2 Jun 2008 12:17:19 -0300 Subject: Proposed changes to workflow bug management In-Reply-To: <1212411215.8011.239.camel@cunning> References: <20080601231751.GE6087@async.com.br> <1212411215.8011.239.camel@cunning> Message-ID: <20080602151719.GJ6087@async.com.br> On Mon, Jun 02, 2008 at 08:53:35AM -0400, Ben Collins wrote: > I don't see that as being true. First off, it's not assigned to the team > until it is triaged and secondly, before it is triaged, it can be > assigned to the triager. Well... assignment, in Launchpad, means "the person who is responsible for fixing this bug". While today the UI may make that not such a hard constraint, it's likely to evolve in this direction over the future, which is why I'm saying it's ideal if we align our visions. > Also, when it is assigned to a team, the entire team is responsible for > bringing it to the next step, and contacting the team is as easy as > contacting a single person (thanks to launchpad :). Not really. You can't, for instance, email the team (unless it has a contact email address, which is a bit of a corner case). > Having a list of bugs to work from is the loose sense of the reason it > is being used. The real use is to be able to separate responsibilities > within a single package. Hmmm. What's the practical difference between the two things, apart from email notifications? > I believe I've stated to the LP team once or twice in the past, that > being able to control the tags associated to a particular package would > make this easy to do without assigning to a team (would also make tags > much more useful), but something with more visibility would be best. What do you mean by "more visibility"? I think we're getting somewhere, but not sure where yet! :-) -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3376 0125 From ruiboon at gmail.com Mon Jun 2 16:36:29 2008 From: ruiboon at gmail.com (Rui Boon) Date: Tue, 03 Jun 2008 00:36:29 +0800 Subject: Suggestion for canned response for "Packages not provided by Ubuntu" In-Reply-To: References: Message-ID: <4844218D.7090103@gmail.com> Jeff Hanson wrote: > https://wiki.ubuntu.com/Bugs/Responses > > acroread bug #236219 was marked invalid for Hardy. The reason was > confusing as the package is in Launchpad. I quickly figured out it > was because it was in Dapper but is no longer supported by Ubuntu in > current releases. The response should indicate this otherwise > beginners are going to be confused/annoyed. I was going to add it to > the Wiki but decided it was better to let the bug squad members figure > it out. > > That is the reason why i provide the link to report it to correct source. Nevertheless i agree that i should have check further, instead of merely applying the canned response. How does the following sounds (for packages that were once supported but not with the current distribution)? ....However, it seems that the software package is no longer supported by Ubuntu ..... What about packages that are no longer supported in the current distribution and the distribution that once supported it has gone EOL? Will it still exist in launchpad? What about the canned response? From ben.collins at canonical.com Mon Jun 2 16:04:23 2008 From: ben.collins at canonical.com (Ben Collins) Date: Mon, 02 Jun 2008 12:04:23 -0400 Subject: Proposed changes to workflow bug management In-Reply-To: <20080602151719.GJ6087@async.com.br> References: <20080601231751.GE6087@async.com.br> <1212411215.8011.239.camel@cunning> <20080602151719.GJ6087@async.com.br> Message-ID: <1212422663.8011.309.camel@cunning> On Mon, 2008-06-02 at 12:17 -0300, Christian Robottom Reis wrote: > On Mon, Jun 02, 2008 at 08:53:35AM -0400, Ben Collins wrote: > > I don't see that as being true. First off, it's not assigned to the team > > until it is triaged and secondly, before it is triaged, it can be > > assigned to the triager. > > Well... assignment, in Launchpad, means "the person who is responsible > for fixing this bug". While today the UI may make that not such a hard > constraint, it's likely to evolve in this direction over the future, > which is why I'm saying it's ideal if we align our visions. > > > Also, when it is assigned to a team, the entire team is responsible for > > bringing it to the next step, and contacting the team is as easy as > > contacting a single person (thanks to launchpad :). > > Not really. You can't, for instance, email the team (unless it has a > contact email address, which is a bit of a corner case). I don't want to discuss the corner cases where our workflow wouldn't work for some other project/package because of lack of enforcement in LP, since I can't control that :) It really has no bearing on the use case (although I understand it does have bearing on the usability of LP in general). > > Having a list of bugs to work from is the loose sense of the reason it > > is being used. The real use is to be able to separate responsibilities > > within a single package. > > Hmmm. What's the practical difference between the two things, apart from > email notifications? Listing of bugs to work from is important to the person who wants to work on that bug-set. Showing responsibility (to either a team or a person) is something other people are interested in... > > I believe I've stated to the LP team once or twice in the past, that > > being able to control the tags associated to a particular package would > > make this easy to do without assigning to a team (would also make tags > > much more useful), but something with more visibility would be best. > > What do you mean by "more visibility"? I think we're getting somewhere, > but not sure where yet! :-) When other people go to a bug, they would like to know, instantly, where responsibility for this bug lies. Is it the kernel team? Is it the PowerPC port team? Is it the Alsa/Sound team? Who? In some points during our workflow it is impossible to have a bug assigned to a person or no one. The triaged state is one of those points. Examples: #1 Bug says sound isn't working on Apple PowerBook G4. Bug is found to be legit, and is in the snd-aoa driver (powerpc specific). Mark it triaged. #2 Bug says sound isn't working on Apple PowerBook G4. Bug is found to be legit, and is in the snd-core driver (generic across all platforms). Mark it triaged. Now at this point, following customary bug triaging, the bug should be assigned to a person, but a triager can't know who that someone is. So, leave it unassigned. Triager's can be trained to know which general team it is for though. Let's face it, to triage kernel bugs, you need some minimum training anyway. Here's the problem. I (as a Canonical employee hired to work on the kernel), care more about #2 than #1. I don't want to see #1. However, someone on the powerpc-team cares about #1 for sure, and may care about #2, but only in so much that it affects his architecture (the bug may only show up in that particular hardware instance, but it is a general bug none-the-less). Further, if I am the submitter of that bug, or a subscriber to that bug, how do I know who is ultimately going to fix it? Who is going to follow up on the bug? Who should I contact when it gets ignored for some weeks? With no assignee, there's no implied responsibility visible to the submitter or interested parties. With a triager assigning to "just someone", it will get the bug on someone's list, and probably assigned to the right person somewhere down the line, but creates a lot of noise for people on the team. How best to represent this in Launchpad? Right now, it's being able to assign to a team. I'll concede it isn't ideal, but it does solve the problem. From jhansonxi at gmail.com Mon Jun 2 18:01:52 2008 From: jhansonxi at gmail.com (Jeff Hanson) Date: Mon, 2 Jun 2008 14:01:52 -0400 Subject: Suggestion for canned response for "Packages not provided by Ubuntu" In-Reply-To: <4844218D.7090103@gmail.com> References: <4844218D.7090103@gmail.com> Message-ID: On Mon, Jun 2, 2008 at 12:36 PM, Rui Boon wrote: > That is the reason why i provide the link to report it to correct source. > Nevertheless i agree that i should have check further, instead of merely > applying the canned response. Thanks but Medibuntu wasn't exactly helpful either: https://bugs.launchpad.net/medibuntu/+bug/236433 From brian at ubuntu.com Mon Jun 2 23:35:30 2008 From: brian at ubuntu.com (Brian Murray) Date: Mon, 2 Jun 2008 16:35:30 -0700 Subject: Bugs reports about -proposed packages Message-ID: <20080602233530.GO7382@murraytwins.com> Recently there has been some promotion of enabling the Hardy -proposed repository so we can get more testing and feedback about those particular packages. However, it isn't particularly easy to find bug reports about a package in the -proposed repository. Subsequently, I propose (pun intended) that we tag these bug reports as 'proposed-pkg'. As bug triagers we can determine this information by looking at apt-cache policy output, specifically the version table, which should be found in a bug's description. Developers will then be able to search for bug reports about their package with the 'proposed-pkg' tag and the Stable Release Updates team will be able to look at bug reports about packages in the -proposed repository. -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From pedro at ubuntu.com Tue Jun 3 14:14:30 2008 From: pedro at ubuntu.com (Pedro Villavicencio Garrido) Date: Tue, 03 Jun 2008 10:14:30 -0400 Subject: QA Team Meeting - 2008-06-04 Message-ID: <1212502470.14416.13.camel@thylacine> Hello Everybody!, The Wednesday 04 of June we're going to have our next QA Team Meeting in #ubuntu-meeting at 1600 UTC. The agenda for the meeting can be found at: https://wiki.ubuntu.com/QATeam/Meetings Please feel free to add items you want to discuss during it. Have a nice day, pedro. From laserjock.ubuntu at gmail.com Tue Jun 3 16:22:04 2008 From: laserjock.ubuntu at gmail.com (Jordan Mantha) Date: Tue, 3 Jun 2008 09:22:04 -0700 Subject: SRU testing opportunities Message-ID: <8d41218e0806030922v2362aa05w6753f78cbdf14de2@mail.gmail.com> Hello bugsquaders! I'm a member of the MOTU SRU team, which means I look after stable release updates in Universe and Multiverse. When we need to push important fixes and updates to users of the stable Ubuntu releases we use the -proposed repository for testing prior to moving packages into the -updates repository. Anyway, I thought you all might be interested in helping out with some testing so I've got a list here of the ones we're having a hard time getting tested (they've been sitting in -proposed for a long time). Testing involves reading the bug report to find the test case, the specific steps to follow to reproduce the bug so that we can confirm that it has been fixed. Note that this needs to be done on the release we are targeting (could be Dapper, Feisty, Gutsy, or Hardy) though testing in VMs is usually fine. If there isn't a specific test case in the bug report and you're unsure of how to reproduce let me know or add a note to the bug report. * http://bugs.launchpad.net/bugs/187271 sun-java5 in dapper is being updated so just test normal Java functionality * http://bugs.launchpad.net/bugs/204221 icedtea-java7 in gutsy has several bugs being fixed (listed in the description) * http://bugs.launchpad.net/bugs/199014 pyslide in hardy is missing a dependency on python-xml. This bug report is very messy but the Test Case at the top of the description should be clear enough :-) * http://bugs.launchpad.net/bugs/221973 smstools in hardy removed the /var/run/smstools folder on shutdown but fails to recreated it at startup By the way, if you're bored (you know, 'cause we have so few bugs ;-) ), the current SRUs in -proposed, and hence need testing, can be found at: http://people.ubuntu.com/~ubuntu-archive/pending-sru.html You can also find the bugs tagged with "verification-needed": https://bugs.launchpad.net/ubuntu/+bugs?field.tag=verification-needed Let me know if you need help or something's unclear. Thanks for any help you can provide. -Jordan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at ubuntu.com Tue Jun 3 20:24:53 2008 From: brian at ubuntu.com (Brian Murray) Date: Tue, 3 Jun 2008 13:24:53 -0700 Subject: A bug checklist Message-ID: <20080603202453.GU7382@murraytwins.com> I thought it might be helpful if we were to have a bug checklist of things to do with bug reports in any given state. Subsequently, Leann, Pedro and I drew one[0] up. My thought is that this is something new triagers could have at their side when triaging bug reports. So while there are a phenomenal number of things that could be done to a bug report our hope was to capture the most common ones. Please try using it as you are working on bug reports and provide feedback here or on the wiki page itself! [0] https://wiki.ubuntu.com/Bugs/Checklist Thanks, -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From thekorn at gmx.de Wed Jun 4 08:21:14 2008 From: thekorn at gmx.de (markus korn) Date: Wed, 4 Jun 2008 10:21:14 +0200 Subject: A bug checklist In-Reply-To: <20080603202453.GU7382@murraytwins.com> References: <20080603202453.GU7382@murraytwins.com> Message-ID: <7533d3600806040121j271d672sabcc5db4041f9a14@mail.gmail.com> Good work! - But what about a 'workflow bug' item in the 'any state'-section, maybe linked to [0]. Markus [0] https://wiki.ubuntu.com/Bugs/HowToTriage#head-0670f256d42484d8f9d0cec896eb2c05e43388e3 From mrooney at gmail.com Wed Jun 4 14:04:34 2008 From: mrooney at gmail.com (Mike Rooney) Date: Wed, 4 Jun 2008 10:04:34 -0400 Subject: A bug checklist In-Reply-To: <20080603202453.GU7382@murraytwins.com> References: <20080603202453.GU7382@murraytwins.com> Message-ID: <4f4806ee0806040704r1d44ab35lc402ab6b8b2575cb@mail.gmail.com> Excellent work, this looks like a great resource indeed! On Tue, Jun 3, 2008 at 4:24 PM, Brian Murray wrote: > I thought it might be helpful if we were to have a bug checklist of > things to do with bug reports in any given state. Subsequently, Leann, > Pedro and I drew one[0] up. My thought is that this is something new > triagers could have at their side when triaging bug reports. So while > there are a phenomenal number of things that could be done to a bug > report our hope was to capture the most common ones. > > Please try using it as you are working on bug reports and provide > feedback here or on the wiki page itself! > > [0] https://wiki.ubuntu.com/Bugs/Checklist > > Thanks, > -- > Brian Murray @ubuntu.com > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIRaiVDTAwc5ER+zURAmLbAKCObrkHcDYG5x1qf50uCsXGfX8dJgCg1MCS > PwrssfnQzkvzDOw8ulbjMzE= > =R15I > -----END PGP SIGNATURE----- > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -- Mike Rooney mrooney at gmail.com From brian at ubuntu.com Fri Jun 6 18:48:37 2008 From: brian at ubuntu.com (Brian Murray) Date: Fri, 6 Jun 2008 11:48:37 -0700 Subject: Hug Day - 10 June 2008 Message-ID: <20080606184837.GO7382@murraytwins.com> The next hug day is on Tuesday, June 10th and will be focused on the update-manager package. We'll be following up with reporters, documenting test cases, confirming bug reports, and moving bugs from confirmed to triaged. The event will be held in #ubuntu-bugs on Freenode. The list of targeted bugs and tasks is posted at: https://wiki.ubuntu.com/UbuntuBugDay/20080610 Our goal is to deal with all of the bugs on that list. So on 10 June 2008, in all timezones, we'll be meeting in #ubuntu-bugs on irc.freenode.net for another Ubuntu Hug Day. https://wiki.ubuntu.com/UbuntuBugDay While you are welcome to apply to join the Ubuntu Bug Control team anytime, Hug Day is a great day to join! https://wiki.ubuntu.com/UbuntuBugControl If you're interested in helping to make the next release of Ubuntu even better - please stop by. And feel free to ask bdmurray, ogasawara, pedro and the rest of the team for ways to help out. We hope to see you there and your name on the list of bug triagers! Sincerely, -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From pedro at ubuntu.com Tue Jun 10 16:14:42 2008 From: pedro at ubuntu.com (Pedro Villavicencio Garrido) Date: Tue, 10 Jun 2008 12:14:42 -0400 Subject: QA Team Meeting - 2008-06-11 Message-ID: <1213114482.13354.5.camel@thylacine> Hello Ubuntu Lovers, The Wednesday 11 of June we're going to have our next QA Team Meeting in #ubuntu-meeting at 1700 UTC[1]. The agenda for the meeting can be found at: https://wiki.ubuntu.com/QATeam/Meetings Please feel free to add items you want to discuss during it. 1- http://fridge.ubuntu.com/node/1509 Have a nice day, pedro. From pedro at ubuntu.com Tue Jun 10 21:01:30 2008 From: pedro at ubuntu.com (Pedro Villavicencio Garrido) Date: Tue, 10 Jun 2008 17:01:30 -0400 Subject: Celebrating Hug Day! - 12 June 2008 Message-ID: <1213131690.6090.51.camel@thylacine> Hello Ubuntu Lovers, On Thursday 12 of June we'll be celebrating a Compiz Hug Day!, our goal is to deal with all of the bugs on this list: https://wiki.ubuntu.com/UbuntuBugDay/20080612 Who can join the Hug Day? Everyone. You don't need to be a developer. You don't need to know to code. Everyone is welcome. If you don't know how to help, then just come and we'll explain you everything. In a Bug Day, you can * work in a nice team, * make sure the bug reporters' concerns are heard, * gather all the information needed so developers can fix bugs, * close useless bugs, * find out where the bugs come from, * do a lot of 5-a-day, and eventually * work together with upstream to make changes happen, * get experience in hacking and fixing bugs. Where to join the Hug Day? #ubuntu-bugs on freenode IRC. And you can go there every other day too! When to join the Hug Day? Next hug day is on Thursday 12 of June In all timezones. But again, you can go there every day and help with triaging the bug tracking systems. While you are welcome to apply to join the Ubuntu Bug Control team at anytime, Hug Day is a great day to join! https://wiki.ubuntu.com/UbuntuBugControl If you're interested in helping to make the next release of Ubuntu even better - please stop by. And feel free to ask bdmurray, ogasawara, pedro, heno and the rest of the team for ways to help out. We hope to see you there and your name on the list of bug triagers! Have a nice day, pedro. From siretart at ubuntu.com Tue Jun 10 21:02:08 2008 From: siretart at ubuntu.com (Reinhard Tartler) Date: Tue, 10 Jun 2008 23:02:08 +0200 Subject: needs-packaging Example In-Reply-To: (Caroline Ford's message of "Tue, 10 Jun 2008 20:21:35 +0100") References: <484EC6B6.1020602@gmail.com> <8763sh2kbv.fsf@faui44a.informatik.uni-erlangen.de> <200806101518.47175.ubuntu@kitterman.com> Message-ID: <87ve0h0zsf.fsf@faui44a.informatik.uni-erlangen.de> [ fullquote to retain context for the bugsquad list ] "Caroline Ford" writes: > 2008/6/10 Scott Kitterman : >> On Tuesday 10 June 2008 14:53, Reinhard Tartler wrote: >>> David Futcher writes: >>> > Hey Everyone >>> > >>> > I recently noticed that a lot of the needs-packaging bugs on Launchpad >>> > dont have the correct information in them so I wrote up a quick >>> > example of what I think is a 'perfect' need-packaging bug. >>> > >>> > I stuck it up on the wiki at >>> > https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages/ExamplePackageReque >>> >st. >>> > >>> > Has anyone got any feedback/suggestions on it? I think it should be >>> > merged in with another page somewhere, but I dont really know where to >>> > put it? >>> > >>> > Thanks >>> > >>> > David Futcher (bobbo) >>> >>> Thank you for your template, I think it is excellent! I just wonder how >>> we can promote it so that users actually use them? >>> >> I'd suggest link to it from whatever piece of documentation suggest filing >> needs-packaging bugs. > > Bugsquad wiki pages would be good, there is a list of templates that > bug squad members can paste into bugs if they aren't filed correctly. Additional recommendations/instructions for triagers and bugsquad members: - is the bug already filed as ITP/RFP bug in debian? If yes, add a remote bugwatch to the debian bug. Many packages are already requested in debian. Linking the bugs greatly helps finding someone to actually work on the package, really! - is the package already in the archive? From time to time people forget to close the bug in launchpad. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From brian at ubuntu.com Tue Jun 10 22:03:00 2008 From: brian at ubuntu.com (Brian Murray) Date: Tue, 10 Jun 2008 15:03:00 -0700 Subject: meta package bug reports Message-ID: <20080610220300.GJ7382@murraytwins.com> The bugs without a package are a well known blind spot for Ubuntu bug reports, but there is another group that I'd like us to be aware of. There are several meta packages in the distribution that end up receiving all kinds of bug reports, granted at a much smaller quantity than the bugs without package. It'd be great if we could work on triaging these and ensuring that they get assigned to the proper package. The three top, measured by quantity of new reports, meta packages are: linux-meta[0] - 209 ubuntu-meta[1] - 62 kubuntu-meta[2] - 19 Let's try to ensure that all these bugs really deserve to be filed about a -meta package. [0] https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bugs [1] https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bugs [2] https://bugs.launchpad.net/ubuntu/+source/kubuntu-meta/+bugs -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From bobbocanfly at googlemail.com Tue Jun 10 22:13:03 2008 From: bobbocanfly at googlemail.com (David Futcher) Date: Tue, 10 Jun 2008 23:13:03 +0100 Subject: needs-packaging Example In-Reply-To: <87ve0h0zsf.fsf@faui44a.informatik.uni-erlangen.de> References: <484EC6B6.1020602@gmail.com> <8763sh2kbv.fsf@faui44a.informatik.uni-erlangen.de> <200806101518.47175.ubuntu@kitterman.com> <87ve0h0zsf.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <484EFC6F.900@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Reinhard Tartler wrote: > [ fullquote to retain context for the bugsquad list ] > > "Caroline Ford" writes: >> 2008/6/10 Scott Kitterman : >>> On Tuesday 10 June 2008 14:53, Reinhard Tartler wrote: >>>> David Futcher writes: >>>>> Hey Everyone >>>>> >>>>> I recently noticed that a lot of the needs-packaging bugs on Launchpad >>>>> dont have the correct information in them so I wrote up a quick >>>>> example of what I think is a 'perfect' need-packaging bug. >>>>> >>>>> I stuck it up on the wiki at >>>>> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages/ExamplePackageReque >>>>> st. >>>>> >>>>> Has anyone got any feedback/suggestions on it? I think it should be >>>>> merged in with another page somewhere, but I dont really know where to >>>>> put it? >>>>> >>>>> Thanks >>>>> >>>>> David Futcher (bobbo) >>>> Thank you for your template, I think it is excellent! I just wonder how >>>> we can promote it so that users actually use them? >>>> >>> I'd suggest link to it from whatever piece of documentation suggest filing >>> needs-packaging bugs. >> Bugsquad wiki pages would be good, there is a list of templates that >> bug squad members can paste into bugs if they aren't filed correctly. > > Additional recommendations/instructions for triagers and bugsquad > members: > > - is the bug already filed as ITP/RFP bug in debian? If yes, add a > remote bugwatch to the debian bug. Many packages are already > requested in debian. Linking the bugs greatly helps finding someone > to actually work on the package, really! > > - is the package already in the archive? From time to time people > forget to close the bug in launchpad. Thanks for the feedback everyone. I have added a link to the example on https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages. I also wrote a stock response for incomplete needs-packaging bugs at https://wiki.ubuntu.com/Bugs/Responses#head-ce88657d362e4aa60fe1dcc1c3ed78eaafcc8209. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFITvxvc/GdKypR+80RAjt2AJ0crbCJIqSJhi7LmpMvOd2FyhjzXACfXPGz xy+u0zH99jsOaKQwElvW5lg= =GXVa -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.holbach at ubuntu.com Wed Jun 11 08:46:29 2008 From: daniel.holbach at ubuntu.com (Daniel Holbach) Date: Wed, 11 Jun 2008 10:46:29 +0200 Subject: Global Bug Jam - your help needed! Message-ID: <484F90E5.7070808@ubuntu.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everybody, you might have heard about the next big thing: the Ubuntu Global Bug Jam. If not, check out https://wiki.ubuntu.com/GlobalBugJam - we're basically going to run a GIANT Hug Day all around the globe and have Bug Jams all over the place. I'm writing to you because you're the backbone of our Bug community. You deal with bugs every day and you know your way around: - bug processes - bug statuses - debugging information - scripts that make life easier - 5-a-day You know it all. If you want to help your LoCo to organise the event [1] that's great, but the thing that would help most is just agreeing to help your local friends to get started and answer questions as they arise. If you could send a mail to your LoCo or LUG and say "Hey, let's participate in the Global Bug Jam! I'm happy to give a short introduction and answer questions." that'd be awesome. This event is going to ROCK heavily. Let's help our local friends to put their brick into the wall. :-) Have a great day, Daniel [1] https://wiki.ubuntu.com/RunningBugJam - -- My 5 today: #239036 (gpsk31), #237726 (streamtuner), #238051 (fwbuilder), #238991 (devhelp), #237042 (tablelist) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIT5DkRjrlnQWd1esRAh9fAJ96Ceqkrjw1wqu3oewRJ83nhJDJJACfRPVX aXWmAy6afMBz5nU7YgeWiVY= =6L1Q -----END PGP SIGNATURE----- From siretart at ubuntu.com Wed Jun 11 09:16:28 2008 From: siretart at ubuntu.com (Reinhard Tartler) Date: Wed, 11 Jun 2008 11:16:28 +0200 Subject: needs-packaging Example In-Reply-To: <484EFC6F.900@gmail.com> (David Futcher's message of "Tue, 10 Jun 2008 23:13:03 +0100") References: <484EC6B6.1020602@gmail.com> <8763sh2kbv.fsf@faui44a.informatik.uni-erlangen.de> <200806101518.47175.ubuntu@kitterman.com> <87ve0h0zsf.fsf@faui44a.informatik.uni-erlangen.de> <484EFC6F.900@gmail.com> Message-ID: <87myls72mr.fsf@faui44a.informatik.uni-erlangen.de> David Futcher writes: > Thanks for the feedback everyone. I have added a link to the example > on https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages. I also wrote > a stock response for incomplete needs-packaging bugs at > https://wiki.ubuntu.com/Bugs/Responses#head-ce88657d362e4aa60fe1dcc1c3ed78eaafcc8209. Please not that needs-packaging bugs should never be set to 'incomplete' to prevent bug expiry. There is really no point in expiring needs-packaging bugs, at some point someone will or will not package it. Thinking a bit more about bug statuses, I don't see why needs-packaging bugs should ever be 'confirmed'. What semantics should 'confirmed' have? Either it is already in the archive, then it should be marked 'fixreleased', or it become obsolete, in which case it should be in state 'invalid'/'rejected'. If someone actually starts packaging on it, he should set himself as assignee and mark the bug as 'inprogress'. Bugs 'inprogress' without assignees are pointless and should go back to 'new' IMO. If nobody seriously disagrees with this triaging instructions, could the bugsquad please integrate this instructions properly at the relevant places of the existing documentation? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From caroline.ford.work at googlemail.com Wed Jun 11 11:47:11 2008 From: caroline.ford.work at googlemail.com (Caroline Ford) Date: Wed, 11 Jun 2008 12:47:11 +0100 Subject: needs-packaging Example In-Reply-To: <87myls72mr.fsf@faui44a.informatik.uni-erlangen.de> References: <484EC6B6.1020602@gmail.com> <8763sh2kbv.fsf@faui44a.informatik.uni-erlangen.de> <200806101518.47175.ubuntu@kitterman.com> <87ve0h0zsf.fsf@faui44a.informatik.uni-erlangen.de> <484EFC6F.900@gmail.com> <87myls72mr.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: 2008/6/11 Reinhard Tartler : > > David Futcher writes: > >> Thanks for the feedback everyone. I have added a link to the example >> on https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages. I also wrote >> a stock response for incomplete needs-packaging bugs at >> https://wiki.ubuntu.com/Bugs/Responses#head-ce88657d362e4aa60fe1dcc1c3ed78eaafcc8209. > > Please not that needs-packaging bugs should never be set to 'incomplete' > to prevent bug expiry. There is really no point in expiring > needs-packaging bugs, at some point someone will or will not package > it. > > Thinking a bit more about bug statuses, I don't see why needs-packaging > bugs should ever be 'confirmed'. What semantics should 'confirmed' have? > Either it is already in the archive, then it should be marked > 'fixreleased', or it become obsolete, in which case it should be in > state 'invalid'/'rejected'. > > If someone actually starts packaging on it, he should set himself as > assignee and mark the bug as 'inprogress'. Bugs 'inprogress' without > assignees are pointless and should go back to 'new' IMO. > > If nobody seriously disagrees with this triaging instructions, could the > bugsquad please integrate this instructions properly at the relevant > places of the existing documentation? We confirm that it actually needs packaging - that it's not in the archive. I also look for duplicate requests, and check Debian. Caroline From wolfger at gmail.com Wed Jun 11 14:14:54 2008 From: wolfger at gmail.com (Wolfger) Date: Wed, 11 Jun 2008 10:14:54 -0400 Subject: needs-packaging Example In-Reply-To: References: <484EC6B6.1020602@gmail.com> <8763sh2kbv.fsf@faui44a.informatik.uni-erlangen.de> <200806101518.47175.ubuntu@kitterman.com> <87ve0h0zsf.fsf@faui44a.informatik.uni-erlangen.de> <484EFC6F.900@gmail.com> <87myls72mr.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <3b00b3330806110714y75a15ac6g9b0d45ea65bc93e4@mail.gmail.com> On Wed, Jun 11, 2008 at 7:47 AM, Caroline Ford wrote: >> If nobody seriously disagrees with this triaging instructions, could the >> bugsquad please integrate this instructions properly at the relevant >> places of the existing documentation? > > We confirm that it actually needs packaging - that it's not in the > archive. I also look for duplicate requests, and check Debian. That about sums up what I've read here. Also, valid statuses are: New, In Progress, Fix released, or Invalid. Other statuses have no use on needs-packaging bugs. -- Wolfger http://wolfger.wordpress.com/ My 5 today: #69019 (nfs-utils, gnat-gps, update-manager), #194279 (linux-source-2.6.22), #191055 (firefox), #73390 (kipina), #137584 (sane-backends) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day From sh at sourcecode.de Wed Jun 11 06:12:48 2008 From: sh at sourcecode.de (Stephan Hermann) Date: Wed, 11 Jun 2008 08:12:48 +0200 Subject: needs-packaging Example In-Reply-To: <484EFC6F.900@gmail.com> References: <484EC6B6.1020602@gmail.com> <8763sh2kbv.fsf@faui44a.informatik.uni-erlangen.de> <200806101518.47175.ubuntu@kitterman.com> <87ve0h0zsf.fsf@faui44a.informatik.uni-erlangen.de> <484EFC6F.900@gmail.com> Message-ID: <20080611081248.2c3b5d50@wz-pc-006.intern.netviewer.de> Moins, On Tue, 10 Jun 2008 23:13:03 +0100 David Futcher wrote: > Thanks for the feedback everyone. I have added a link to the example > on https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages. I also wrote > a stock response for incomplete needs-packaging bugs at > https://wiki.ubuntu.com/Bugs/Responses#head-ce88657d362e4aa60fe1dcc1c3ed78eaafcc8209. Please note, that nobody should touch needs-packaging bugs already assigned to ubuntu devs, please. For me, I'm filing needs-packaging bugs, just as a reminder what I still have to do ... \sh From persia at ubuntu.com Wed Jun 11 15:47:09 2008 From: persia at ubuntu.com (Emmet Hikory) Date: Thu, 12 Jun 2008 00:47:09 +0900 Subject: needs-packaging Example In-Reply-To: <3b00b3330806110714y75a15ac6g9b0d45ea65bc93e4@mail.gmail.com> References: <484EC6B6.1020602@gmail.com> <8763sh2kbv.fsf@faui44a.informatik.uni-erlangen.de> <200806101518.47175.ubuntu@kitterman.com> <87ve0h0zsf.fsf@faui44a.informatik.uni-erlangen.de> <484EFC6F.900@gmail.com> <87myls72mr.fsf@faui44a.informatik.uni-erlangen.de> <3b00b3330806110714y75a15ac6g9b0d45ea65bc93e4@mail.gmail.com> Message-ID: <9bd2f8970806110847w73abf2c4l41ff43c5aabb1eca@mail.gmail.com> Wolfger wrote: > Caroline Ford wrote: >> We confirm that it actually needs packaging - that it's not in the >> archive. I also look for duplicate requests, and check Debian. > > That about sums up what I've read here. Also, valid statuses are: New, > In Progress, Fix released, or Invalid. Other statuses have no use on > needs-packaging bugs. What meaning is attached to "Invalid"? Also, might we want "Won't Fix" when there is a request for packaging of something that has a license that prohibits distribution (which status could be changed if the upstream licensing changed). Additionally, I like the use of "Fix Committed" to indicate that a package has been reviewed and uploaded to the archive, but is currently in the NEW queue: this is helpful to indicate where to seek a package, especially as the common procedure is to archive a package from REVU when it is uploaded, even though the archive-admins may be very busy, and might take a couple weeks to accept the package. That said, "Incomplete" isn't a very interesting status for a needs-packaging bug; although the bug report may be incomplete (not have upstream homepage, not have license stated, etc.), we never want these to expire. Where a needs-packaging bug is not assigned, using Google to complete the bug report is a very useful triage action, as this often provides enough context that someone looking for something to package will be able to review the bug. Thinking on that, "Triaged" might be a good way to indicate that a given needs-packaging bug does have all the right information, and that further information is not required prior to assignment to a packager. -- Emmet HIKORY From siretart at ubuntu.com Wed Jun 11 16:37:30 2008 From: siretart at ubuntu.com (Reinhard Tartler) Date: Wed, 11 Jun 2008 18:37:30 +0200 Subject: needs-packaging Example In-Reply-To: <9bd2f8970806110847w73abf2c4l41ff43c5aabb1eca@mail.gmail.com> (Emmet Hikory's message of "Thu, 12 Jun 2008 00:47:09 +0900") References: <484EC6B6.1020602@gmail.com> <8763sh2kbv.fsf@faui44a.informatik.uni-erlangen.de> <200806101518.47175.ubuntu@kitterman.com> <87ve0h0zsf.fsf@faui44a.informatik.uni-erlangen.de> <484EFC6F.900@gmail.com> <87myls72mr.fsf@faui44a.informatik.uni-erlangen.de> <3b00b3330806110714y75a15ac6g9b0d45ea65bc93e4@mail.gmail.com> <9bd2f8970806110847w73abf2c4l41ff43c5aabb1eca@mail.gmail.com> Message-ID: <87bq286i7p.fsf@faui44a.informatik.uni-erlangen.de> "Emmet Hikory" writes: >> That about sums up what I've read here. Also, valid statuses are: New, >> In Progress, Fix released, or Invalid. Other statuses have no use on >> needs-packaging bugs. > > What meaning is attached to "Invalid"? Also, might we want "Won't > Fix" when there is a request for packaging of something that has a > license that prohibits distribution (which status could be changed if > the upstream licensing changed). TBH, these cases would apply to me as 'invalid'. 'wontfix' is a restricted status to triagers and developers, and I see no reason to prevent random users to put their request to this state. In the end, a 'need-packaging' bug is not a real bug report, but rather a packaging request. It has basically 3 states, with two being final: - package is waiting to for someone to package it (new) - the package has reached the archive (fixreleased, final) - the software cannot or should not be packaged (license reasons, obsoleted software, is buggy/unmaintainable etc.) (invalid, final) I'd like to reduce the number of statuses we use on 'needs-packaging' bugs to a minimum to reduce complexity in this process. > Additionally, I like the use of "Fix Committed" to indicate that a > package has been reviewed and uploaded to the archive, but is > currently in the NEW queue: this is helpful to indicate where to seek > a package, especially as the common procedure is to archive a package > from REVU when it is uploaded, even though the archive-admins may be > very busy, and might take a couple weeks to accept the package. Indeed, this could be done, I think this should be done automatically by soyuz then with a proper message in the bug. If we agree on a 'needs-packaging' bug procedure, I will file a bug against launchpad requesting this. > That said, "Incomplete" isn't a very interesting status for a > needs-packaging bug; although the bug report may be incomplete (not > have upstream homepage, not have license stated, etc.), we never want > these to expire. The only case where I can remotely imagine that the status 'incomplete' might make sense is the case that the submitter mentiones a software which cannot be found by google. I'd expect this particular case to be so pathological that I wouldn't explicitly mention it in the documentation, but rather just close such reports. If the submitter really cares, he can still set the bug from 'invalid' back to 'new' again. > Where a needs-packaging bug is not assigned, using Google to complete > the bug report is a very useful triage action, as this often provides > enough context that someone looking for something to package will be > able to review the bug. Indeed, this could motivate potential packagers. > Thinking on that, "Triaged" might be a good way to indicate that a > given needs-packaging bug does have all the right information, and > that further information is not required prior to assignment to a > packager. With 'triaged' being a restricted status, this might make sense. However I don't really see the benefit for that. It's not like motu's are continuely looking at all bugs not assigned to any package tagged 'needs-packaging' in status 'triaged' and start packaging random crack. That's why I don't think the triaging documentation should mandate this status, it's just waste of time doing this, IMO. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From wolfger at gmail.com Fri Jun 13 14:18:01 2008 From: wolfger at gmail.com (Wolfger) Date: Fri, 13 Jun 2008 10:18:01 -0400 Subject: needs-packaging Example In-Reply-To: <87myls72mr.fsf@faui44a.informatik.uni-erlangen.de> References: <484EC6B6.1020602@gmail.com> <8763sh2kbv.fsf@faui44a.informatik.uni-erlangen.de> <200806101518.47175.ubuntu@kitterman.com> <87ve0h0zsf.fsf@faui44a.informatik.uni-erlangen.de> <484EFC6F.900@gmail.com> <87myls72mr.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <3b00b3330806130718s2c14f157o6650f9965e16c0c0@mail.gmail.com> On Wed, Jun 11, 2008 at 5:16 AM, Reinhard Tartler wrote: > > Please note that needs-packaging bugs should never be set to 'incomplete' > to prevent bug expiry. There is really no point in expiring > needs-packaging bugs, at some point someone will or will not package > it. I agreed with this when I first read it, but (of course) when I decided to look at some needs-packaging bugs today, I found one which I felt really did deserve it. Or perhaps it shouldn't have been a "needs-packaging" bug in the first place? ;-) https://bugs.launchpad.net/ubuntu/+source/devil/+bug/130239 -- Wolfger http://wolfger.wordpress.com/ My 5 today: #69019 (nfs-utils, gnat-gps, update-manager), #194279 (linux-source-2.6.22), #191055 (firefox), #73390 (kipina), #137584 (sane-backends) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day From brian at ubuntu.com Fri Jun 13 19:58:26 2008 From: brian at ubuntu.com (Brian Murray) Date: Fri, 13 Jun 2008 12:58:26 -0700 Subject: Hug Day - 17 June 2008 Message-ID: <20080613195826.GE7382@murraytwins.com> The OpenOffice.org maintainer has been doing a heroic job of handling bug reports regarding OpenOffice but he can still use your help! Subsequently, the next hug day, on Tuesday, June 17th, will focus on OpenOffice. There are currently about 214 New bug reports regarding Open Office and we will be focusing on reducing that number in addition to look at some outstanding Incomplete and Confirmed bugs. We'll do this by following up with reporters, documenting test cases, confirming bug reports and tagging bugs based on their sub-component. The event will be held in #ubuntu-bugs on Freenode. The list of targeted bugs and tasks is posted at: https://wiki.ubuntu.com/UbuntuBugDay/20080617 Our goal is to deal with all of the bugs on that list. So on 17 June 2008, in all timezones, we'll be meeting in #ubuntu-bugs on irc.freenode.net for another Ubuntu Hug Day. https://wiki.ubuntu.com/UbuntuBugDay While you are welcome to apply to join the Ubuntu Bug Control team anytime, Hug Day is a great day to join! https://wiki.ubuntu.com/UbuntuBugControl If you're interested in helping to make the next release of Ubuntu even better - please stop by. And feel free to ask bdmurray, pedro, calc (the OpenOffice maintainer) and the rest of the team for ways to help out. We hope to see you there and your name on the list of bug triagers! Sincerely, -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From persia at ubuntu.com Sat Jun 14 01:01:59 2008 From: persia at ubuntu.com (Emmet Hikory) Date: Sat, 14 Jun 2008 10:01:59 +0900 Subject: needs-packaging Example In-Reply-To: <3b00b3330806130718s2c14f157o6650f9965e16c0c0@mail.gmail.com> References: <484EC6B6.1020602@gmail.com> <8763sh2kbv.fsf@faui44a.informatik.uni-erlangen.de> <200806101518.47175.ubuntu@kitterman.com> <87ve0h0zsf.fsf@faui44a.informatik.uni-erlangen.de> <484EFC6F.900@gmail.com> <87myls72mr.fsf@faui44a.informatik.uni-erlangen.de> <3b00b3330806130718s2c14f157o6650f9965e16c0c0@mail.gmail.com> Message-ID: <9bd2f8970806131801w5e4d76bg64993b837fb3ff0f@mail.gmail.com> Wolfger wrote: > On Wed, Jun 11, 2008 at 5:16 AM, Reinhard Tartler wrote: >> >> Please note that needs-packaging bugs should never be set to 'incomplete' >> to prevent bug expiry. There is really no point in expiring >> needs-packaging bugs, at some point someone will or will not package >> it. > > I agreed with this when I first read it, but (of course) when I > decided to look at some needs-packaging bugs today, I found one which > I felt really did deserve it. Or perhaps it shouldn't have been a > "needs-packaging" bug in the first place? ;-) > https://bugs.launchpad.net/ubuntu/+source/devil/+bug/130239 No, that bug would be better served by the "upgrade" tag. The "needs-packaging" tag should be reserved for cases where the nature of the bug is that some piece of software is not available in Ubuntu at all, and may be interpreted as a request for someone to package the software in the repositories. The "upgrade" tag is an indicator that the software is outdated, and may be interpreted as a request that someone update the software to a newer upstream version. In the case of the "needs-packaging" bugs, I still believe that "incomplete" isn't a useful status: it ought remain untriaged until someone puts up the useful information (homepage, license, brief description, software name, etc.), after which it's completely triaged: it's generally not worth training submitters about this class of bugs as there are few repeat submitters who are not also packagers. In the case of the "upgrade" bugs, "incomplete" is a very useful status, as the reporter may not have provided enough information about that is happening, or why the upgrade should be done (although in many cases simple verification that the current development repository is less than that requested or upstream is sufficient). In the specific case of bug #130239, the core-bug appears to be related to the texture rendering in some way, and needs more information to determine how to fix it (this may involve moving to 1.6.8rc2, but I'm suspicious about that solution as there appears to have been no final 1.6.8 release, and upstream appears inactive the past two years). I've removed the "needs-packaging" tag from this bug, and not added the "upgrade" tag, as I am not sure if an upgrade would fix the reported problem. -- Emmet HIKORY From jw+debian at jameswestby.net Mon Jun 16 09:05:35 2008 From: jw+debian at jameswestby.net (James Westby) Date: Mon, 16 Jun 2008 10:05:35 +0100 Subject: MOTU School Session - Apport retraces on 26 June Message-ID: <1213607135.23353.4.camel@flash> Hi all, After a bit of a break for Open Week and UDS MOTU School is back. This months session is going to be presented by Emmet Hikory. It is entitled "Effectively using and interpreting apport retraces." The session will be at 10:00 UTC on Thu 26th June. Also, hello to the bugsquad, I copied you on this mail as you deal with apport a lot, and so you may find this session useful. Thanks, James From brian at ubuntu.com Mon Jun 16 17:37:13 2008 From: brian at ubuntu.com (Brian Murray) Date: Mon, 16 Jun 2008 10:37:13 -0700 Subject: QA Schedule for Intrepid Message-ID: <20080616173713.GI7382@murraytwins.com> The Ubuntu QA Team, which is compromised of the Bug Squad and testing teams, has a wide variety of duties during the development cycle for a release of Ubuntu. To help identify focus areas for any point in the release cycle we've created a QA schedule[0] for Intrepid which is a parallel to the Intrepid Release Schedule[1]. I hope you find this resource helpful in guiding any work you do! [0] https://wiki.ubuntu.com/QATeam/IntrepidSchedule [1] https://wiki.ubuntu.com/IntrepidReleaseSchedule -- Brian Murray @ubuntu.com From pedro at ubuntu.com Tue Jun 17 20:59:40 2008 From: pedro at ubuntu.com (Pedro Villavicencio Garrido) Date: Tue, 17 Jun 2008 16:59:40 -0400 Subject: Celebrating Hug Day! - 19 June 2008 Message-ID: <1213736380.7592.48.camel@thylacine> Hello Ubuntu Lovers, This Thursday 19 of June you need to be ready to squash some bugs because we'll be celebrating a GNOME Power Manager Hug Day!, our goal is to deal with all of the bugs on this list: https://wiki.ubuntu.com/UbuntuBugDay/20080619 Who can join the Hug Day? Everyone. You don't need to be a developer. You don't need to know to code. Everyone is welcome. If you don't know how to help, then just come and we'll explain you everything. In a Bug Day, you can * work in a nice team, * make sure the bug reporters concerns are heard, * gather all the information needed so developers can fix bugs, * close useless bugs, * find out where the bugs come from, * do a lot of 5-a-day!, and eventually * work together with upstream to make changes happen, * get experience in hacking and fixing bugs. Where to join the Hug Day? #ubuntu-bugs on freenode IRC. And you can go there every other day too! When to join the Hug Day? Next hug day is on Thursday 19 of June In all timezones. But again, you can go there every day and help with triaging the bug tracking systems. While you are welcome to apply to join the Ubuntu Bug Control team at anytime, Hug Day is a great day to join! https://wiki.ubuntu.com/UbuntuBugControl If you're interested in helping to make the next release of Ubuntu even better - please stop by. And feel free to ask bdmurray, pedro, heno and the rest of the Ubuntu Bug Squad team for ways to help out. We hope to see you there and your name on the list of bug triagers! Have a nice day, pedro. From sistpoty at ubuntu.com Tue Jun 17 21:56:33 2008 From: sistpoty at ubuntu.com (Stefan Potyra) Date: Tue, 17 Jun 2008 23:56:33 +0200 Subject: Celebrating Hug Day! - 19 June 2008 In-Reply-To: <1213736380.7592.48.camel@thylacine> References: <1213736380.7592.48.camel@thylacine> Message-ID: <200806172356.36680.sistpoty@ubuntu.com> Hi, just a pet peeve from me: can you eventually drop ubuntu-motu from the recievers list of hug day inviations? I guess/hope most of ubuntu-motu subscribers are also reading ubuntu-devel-announce. Cheers, Stefan. P.S.: please CC me on replies, I'm not subscribed to ubuntu-bugsquad at l.u.c -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From craig at decafbad.net Wed Jun 18 11:48:26 2008 From: craig at decafbad.net (Craig Maloney) Date: Wed, 18 Jun 2008 07:48:26 -0400 Subject: How to handle non-free bugs? Message-ID: <1213789706.27812.20.camel@lister> Hello, A bug report came in about gnuplot that I'm a bit unsure how to escalate. The bug is that gnuplot is regarded as free software, when the license is anything but. Here's a link to the bug: https://bugs.launchpad.net/ubuntu/+source/gnuplot/+bug/195111 Is there a standard tagging or escalation path for bugs like these? I found a similar discussion about non-free Firefox add-ons, but didn't get a clear direction from the comments. Thanks! -- ------------------------------------------------------------------- Craig Maloney (craig at decafbad.net) http://decafbad.net Work Hard. Rock Hard. Eat Hard. Sleep Hard. Grow Big. Wear Glasses If You Need 'Em. -- The Webb Wilder Credo From pedro at ubuntu.com Wed Jun 18 12:05:18 2008 From: pedro at ubuntu.com (Pedro Villavicencio Garrido) Date: Wed, 18 Jun 2008 08:05:18 -0400 Subject: QA Team Meeting - Jun 18 2008 Message-ID: <1213790718.6002.4.camel@thylacine> Hello Ubuntu Lovers, The Wednesday 18 of June (Today) we're going to have our next QA Team Meeting in #ubuntu-meeting at 1700 UTC[1]. The agenda for the meeting can be found at: https://wiki.ubuntu.com/QATeam/Meetings Please feel free to add items you want to discuss during it. 1- http://fridge.ubuntu.com/node/1508 Have a nice day, pedro. From hobbsee at ubuntu.com Wed Jun 18 12:12:17 2008 From: hobbsee at ubuntu.com (Sarah Hobbs) Date: Wed, 18 Jun 2008 22:12:17 +1000 Subject: How to handle non-free bugs? In-Reply-To: <1213789706.27812.20.camel@lister> References: <1213789706.27812.20.camel@lister> Message-ID: <4858FBA1.9060101@ubuntu.com> Craig Maloney wrote: > Hello, > > A bug report came in about gnuplot that I'm a bit unsure how to > escalate. The bug is that gnuplot is regarded as free software, when the > license is anything but. Here's a link to the bug: > > https://bugs.launchpad.net/ubuntu/+source/gnuplot/+bug/195111 > > Is there a standard tagging or escalation path for bugs like these? I > found a similar discussion about non-free Firefox add-ons, but didn't > get a clear direction from the comments. > > Thanks! > What I did was asked an archive admin in #ubuntu-devel. The bug has been updated with his comments. I'm unaware of specific tags, but it may just not be an area that I deal in, so don't know about. Hobbsee -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From siretart at ubuntu.com Wed Jun 18 12:34:27 2008 From: siretart at ubuntu.com (Reinhard Tartler) Date: Wed, 18 Jun 2008 14:34:27 +0200 Subject: How to handle non-free bugs? In-Reply-To: <1213789706.27812.20.camel@lister> (Craig Maloney's message of "Wed, 18 Jun 2008 07:48:26 -0400") References: <1213789706.27812.20.camel@lister> Message-ID: <87d4mec46k.fsf@faui44a.informatik.uni-erlangen.de> Craig Maloney writes: > Hello, > > A bug report came in about gnuplot that I'm a bit unsure how to > escalate. The bug is that gnuplot is regarded as free software, when the > license is anything but. Here's a link to the bug: > > https://bugs.launchpad.net/ubuntu/+source/gnuplot/+bug/195111 > > Is there a standard tagging or escalation path for bugs like these? I > found a similar discussion about non-free Firefox add-ons, but didn't > get a clear direction from the comments. With my ubuntu developer hat on, I think the bug was handled exactly right. Severity critical is justified by the fact that the package might not be redistributable and might need to be removed quickly by the archive admins. Having said this, these bugs should be escalated to the Archive Administrators that have the last say on the cause. In complicated cases it can be useful for notifying ubuntu-motu at l.u.c and/or ubuntu-devel at l.u.c in order to get further input. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From brian at ubuntu.com Wed Jun 18 21:07:42 2008 From: brian at ubuntu.com (Brian Murray) Date: Wed, 18 Jun 2008 14:07:42 -0700 Subject: Modifying a bug's description Message-ID: <20080618210742.GN7382@murraytwins.com> Bug descriptions are something that do not get modified very often, approximately 240 times this month, but are a great way to make bug reports more useful. They can also save everyone the pain of having to read through every bug comment to extract important information. I put some thought into a few items[0] that would be beneficial to have in the bug description. This includes a 'test case' section which is currently being used for the Stable Release Update verification process with great success. What other information could we be adding to the bug description to make it more useful? [0] https://wiki.ubuntu.com/Bugs/Description -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From jw+debian at jameswestby.net Wed Jun 18 21:57:11 2008 From: jw+debian at jameswestby.net (James Westby) Date: Wed, 18 Jun 2008 22:57:11 +0100 Subject: Modifying a bug's description In-Reply-To: <20080618210742.GN7382@murraytwins.com> References: <20080618210742.GN7382@murraytwins.com> Message-ID: <1213826231.15831.119.camel@flash> On Wed, 2008-06-18 at 14:07 -0700, Brian Murray wrote: > Bug descriptions are something that do not get modified very often, > approximately 240 times this month, but are a great way to make bug > reports more useful. They can also save everyone the pain of having to > read through every bug comment to extract important information. > > I put some thought into a few items[0] that would be beneficial to have > in the bug description. This includes a 'test case' section which is > currently being used for the Stable Release Update verification process > with great success. What other information could we be adding to the > bug description to make it more useful? Hi Brian, I think making sure the title is good is important as well. Making sure that it describes the problem, and also contains any important words for searching or scanning a bug list, so I'd encourage everyone to always re-evaluate a bug's title when you get some more information. I agree about a test case in the description being useful. I also think including crucial bits of information is also useful so that you don't have to read the whole thing. I saw on the checklist you mentioned including a workaround if a good one is known. Thanks, James From mathiaz at ubuntu.com Wed Jun 18 22:32:07 2008 From: mathiaz at ubuntu.com (Mathias Gug) Date: Wed, 18 Jun 2008 18:32:07 -0400 Subject: Modifying a bug's description In-Reply-To: <1213826231.15831.119.camel@flash> References: <20080618210742.GN7382@murraytwins.com> <1213826231.15831.119.camel@flash> Message-ID: <20080618223207.GE10002@mathiaz.mathiaz.net> On Wed, Jun 18, 2008 at 10:57:11PM +0100, James Westby wrote: > On Wed, 2008-06-18 at 14:07 -0700, Brian Murray wrote: > > Bug descriptions are something that do not get modified very often, > > approximately 240 times this month, but are a great way to make bug > > reports more useful. They can also save everyone the pain of having to > > read through every bug comment to extract important information. > > > > I put some thought into a few items[0] that would be beneficial to have > > in the bug description. This includes a 'test case' section which is > > currently being used for the Stable Release Update verification process > > with great success. What other information could we be adding to the > > bug description to make it more useful? > > I think making sure the title is good is important as well. Making > sure that it describes the problem, and also contains any important > words for searching or scanning a bug list, so I'd encourage everyone > to always re-evaluate a bug's title when you get some more information. > I tend to update a bug's title when I find and mark duplicates (ex: try to merge both bug titles). -- Mathias Gug Ubuntu Developer http://www.ubuntu.com From mpt at canonical.com Thu Jun 19 10:08:25 2008 From: mpt at canonical.com (Matthew Paul Thomas) Date: Thu, 19 Jun 2008 11:08:25 +0100 Subject: Modifying a bug's description In-Reply-To: <20080618210742.GN7382@murraytwins.com> References: <20080618210742.GN7382@murraytwins.com> Message-ID: <485A3019.5000402@canonical.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Murray wrote on 18/06/08 22:07: >... > Bug descriptions are something that do not get modified very often, > approximately 240 times this month, but are a great way to make bug > reports more useful. They can also save everyone the pain of having > to read through every bug comment to extract important information. >... The link for editing a bug report's description will soon be more prominent, hopefully making it more obvious that descriptions can and should be kept up to date. I'm interested to see how much that number will change. Cheers - -- Matthew Paul Thomas http://mpt.net.nz/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIWjAY6PUxNfU6ecoRAvQAAJ48fmnldblhNEpUDp4oVwC+rec4dwCfT2sy uGeh1D7rFwjwvNdt+8Tdoj4= =7XCm -----END PGP SIGNATURE----- From thekorn at gmx.de Thu Jun 19 11:00:32 2008 From: thekorn at gmx.de (markus korn) Date: Thu, 19 Jun 2008 13:00:32 +0200 Subject: Modifying a bug's description In-Reply-To: <20080618210742.GN7382@murraytwins.com> References: <20080618210742.GN7382@murraytwins.com> Message-ID: <7533d3600806190400w8b2a3e0l693263cc1a7fbbad@mail.gmail.com> On Wed, Jun 18, 2008 at 11:07 PM, Brian Murray wrote: > Bug descriptions are something that do not get modified very often, > approximately 240 times this month, but are a great way to make bug > reports more useful. They can also save everyone the pain of having to > read through every bug comment to extract important information. > > I put some thought into a few items[0] that would be beneficial to have > in the bug description. This includes a 'test case' section which is > currently being used for the Stable Release Update verification process > with great success. What other information could we be adding to the > bug description to make it more useful? > > [0] https://wiki.ubuntu.com/Bugs/Description > > -- > Brian Murray @ubuntu.com I understand why it is useful to modify the description of a bugreport: because it is the only possibility launchpad provides us to show important facts to users/developers/triagers in the very first place. But my opinion here is: Nobody should ever change the description of a bugreport! The reporter indicates with his name that he wrote the description, so he is kind of responsible for facts mentioned in the description. I think that's the reason why no one can change comments, because each comment reflects the opinion of its author. Instead of this we should ask the launchpad-devs to implement something like a whitebox section for each bugreport, or a different solution. I understand that such a solution would take some time. In the meantime, part of the 'changing descriptions'-policy should always be a a clear indication like ": added testcase". Markus From hggdh2 at gmail.com Thu Jun 19 12:20:00 2008 From: hggdh2 at gmail.com (HggdH) Date: Thu, 19 Jun 2008 07:20:00 -0500 Subject: Modifying a bug's description In-Reply-To: <7533d3600806190400w8b2a3e0l693263cc1a7fbbad@mail.gmail.com> References: <20080618210742.GN7382@murraytwins.com> <7533d3600806190400w8b2a3e0l693263cc1a7fbbad@mail.gmail.com> Message-ID: <1213878000.5596.42.camel@localhost> > Instead of this we should ask the launchpad-devs to implement > something like a whitebox section for each bugreport, or a different > solution. I understand that such a solution would take some time. I agree, and I really wish this would be implemented by LP development. I would just change 'instead' to 'in addition'. One of my pet peeves on BTSs is how most of them do not allow edit of the description (and almost all of them do not provide areas for what Brian asked for, not even whitebox-like). This is usually based on a perception that we should never change what the reporter said (valid on some situations -- mostly because of legal liabilities --, invalid on others). In our case, we search LP to find bugs that match some scenario we have in mind, and we look at each hit the following way: 1 -- bug title and package -- if the bug title matches what we are looking for, we usually go in. If both the title and package matches, then we certainly go in; 2. -- description -- if the bug title looks promising, we enter the bug and look at the description. 3. -- Nowadays -- we also browse through *all* comments looking for , and (sometimes) skipping through a lot of useless clutter. So summarising the most important facts about a bug in an easily reachable region is important. A direct conclusion is that updating title, package and description helps a lot. adjusting the 'description' field to look like a whitebox helps even more. The whitebox-like area is probably a better initial approach: we do not yet know *all* we would like to have there. It is also most probably THE best approach, allowing for users to adjust as needed without requiring coding. Perhaps we would also benefit from searchable checkboxes like "workaround available". Keep in mind that half of our population is searching LP. > In > the meantime, part of the 'changing descriptions'-policy should always > be a a clear indication like ": added testcase". -1. this just adds more clutter, and we can see who edited the description in the activity log; anyway, a bug entered ceases being owned by the reporter -- it is now a collective piece of work. The reporter goes into History as the reporter; the working bees go into History as a footnote. And... we could use it now. Cheers, ..hggdh.. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dustin.kirkland at gmail.com Thu Jun 19 03:22:28 2008 From: dustin.kirkland at gmail.com (Dustin Kirkland) Date: Wed, 18 Jun 2008 22:22:28 -0500 Subject: Modifying a bug's description In-Reply-To: <20080618210742.GN7382@murraytwins.com> References: <20080618210742.GN7382@murraytwins.com> Message-ID: On Wed, Jun 18, 2008 at 4:07 PM, Brian Murray wrote: > Bug descriptions are something that do not get modified very often, > approximately 240 times this month, but are a great way to make bug > reports more useful. They can also save everyone the pain of having to > read through every bug comment to extract important information. I've modified a couple of bugs' titles that mention one package in the title, but eventually turns out to be a problem in a different package. For the most part, I think the package association (triaging, right?) should be in the "affects" section rather than the "title". When appropriate, I think it's a good idea to leave package references for the "affects" section, rather than the "titles". Descriptions, of course, can provide supporting "evidence", assuming it's current and valid. ----- While we're talking about quality bug reports, I would very much like to see a mechanism to invalidate particular bug comments. Sometimes, it's my own comments (or patches) that I want to "grey out" or "deprecate" or "hide comments below threshold" (a la Slashdot). Occasionally, it's someone else's comments, spam, or "I'm away on vacation" auto response that would be nice to hide. (See bugs #45419 and #220535.) This could really help with some of those 50+ or 100+ comment bugs that "take on a life of their own". These can spiral out of control, subsume and combine other bugs, and become unwieldy to even approach to solve. I know it's a totally different case, but Bug #1 has 700 comments and would benefit from a sort of "rating" system. :-Dustin From kirkland at canonical.com Thu Jun 19 04:01:16 2008 From: kirkland at canonical.com (Dustin Kirkland) Date: Wed, 18 Jun 2008 23:01:16 -0500 Subject: Modifying a bug's description In-Reply-To: References: <20080618210742.GN7382@murraytwins.com> Message-ID: On Wed, Jun 18, 2008 at 10:22 PM, Dustin Kirkland wrote: > I've modified a couple of bugs' titles that mention one package in the > title, but eventually turns out to be a problem in a different > package. For the most part, I think the package association > (triaging, right?) should be in the "affects" section rather than the > "title". Maybe I was a bit too strong with this statement... With a number of packages, the name of the package == the binary == the program affected. Mentioning this in the title is unavoidable. I guess what I'm saying is that there are cases where the title gets out of sync with the affected packages. ie, the affected package is marked "Invalid", while another is "confirmed", but the "invalid" package remains in the title while while the "confirmed" package is not. In these cases, it sometimes helps searching/indexing/reading when the "confirmed" package replaces the "invalid" package mention in the title. :-Dustin From pakdejack at gmail.com Fri Jun 20 07:57:54 2008 From: pakdejack at gmail.com (jacky) Date: Fri, 20 Jun 2008 14:57:54 +0700 Subject: Realtek 8187b WLAN Message-ID: <1213948674.20817.0.camel@ruzm-ubuntuultimate> i've problem with RTL 8187B wireless in my 64 bit hardy,have you find the solution for this problem?? From brian at ubuntu.com Fri Jun 20 23:09:39 2008 From: brian at ubuntu.com (Brian Murray) Date: Fri, 20 Jun 2008 16:09:39 -0700 Subject: Realtek 8187b WLAN In-Reply-To: <1213948674.20817.0.camel@ruzm-ubuntuultimate> References: <1213948674.20817.0.camel@ruzm-ubuntuultimate> Message-ID: <20080620230939.GX7382@murraytwins.com> On Fri, Jun 20, 2008 at 02:57:54PM +0700, jacky wrote: > i've problem with RTL 8187B wireless in my 64 bit hardy,have you find > the solution for this problem?? It's a bit hard to tell if there is a solution for your problem with out know specifics about your issue. Additionally, this mailing list is for discussing how to manage bug reports that are reported in Launchpad. It is not for reporting bugs about Ubuntu. I'd suggest you first look for a bug report that yours may be a duplicate of at: https://bugs.launchpad.net/ubuntu/+source/linux/+bugs In the event that you can not find a bug that yours is a duplicate of, you should submit a new bug report via: https://bugs.launchpad.net/ubuntu/+source/linux/+filebug I hope that is of some assistance! Sincerely, -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From brian at ubuntu.com Sat Jun 21 00:16:59 2008 From: brian at ubuntu.com (Brian Murray) Date: Fri, 20 Jun 2008 17:16:59 -0700 Subject: Patch attachments in Launchpad Message-ID: <20080621001659.GY7382@murraytwins.com> When looking at a bug report with attachments it is hard to identify which ones are flagged as patches. It's also possible that someone's 'dmesg.log' file is flagged as an attachment and you wouldn't know it unless you went to the edit attachment page. This is particularly problematic since it is possible to search for bug reports with patches attached. One could also be in a situation where they were searching for bugs with patches and open a bug report with five attachments and not know which one is flagged as a patch. This led me to write a greasemonkey script[0] that checks to see whether or not an attachment is flagged as a patch. It then modifies the icon next to the relevant attachment from a green download arrow to a star. It does this both in the attachments portlet and in the bug comments. I hope you find it as useful as I do! And please help by unflagging those log files as patches. [0] http://people.ubuntu.com/~brian/greasemonkey/lp_patches.user.js -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From brian at ubuntu.com Sat Jun 21 22:49:04 2008 From: brian at ubuntu.com (Brian Murray) Date: Sat, 21 Jun 2008 15:49:04 -0700 Subject: Hug Day - 24 June 2008 Message-ID: <20080621224904.GZ7382@murraytwins.com> For the next hug day, on Tuesday, June 24th, we will be doing something quite different. We generally focus on moving bugs from the New status to Incomplete or Confirmed, but on the next hug day we'll work on helping move bugs from Fix Committed to Fix Released! We'll do this by verifying that packages in the hardy-proposed repository fix the bugs they were designed to and that the package still functions that way it should. The list of targeted bugs and tasks is posted at: https://wiki.ubuntu.com/UbuntuBugDay/20080624 Our goal is to have at least two people test every bug in that list. So on 24 June 2008, in all timezones, we'll be meeting in #ubuntu-bugs on irc.freenode.net for a very special Ubuntu Hug Day. https://wiki.ubuntu.com/UbuntuBugDay While you are welcome to apply to join the Ubuntu Bug Control team anytime, Hug Day is a great day to join! https://wiki.ubuntu.com/UbuntuBugControl If you're interested in helping to make the Hardy Heron release of Ubuntu even better - please join us. And feel free to ask bdmurray, sbeattie, pedro, heno and the rest of the team for ways to help out. We hope to see you there and your name on the list of testers! Sincerely, -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From polo.pacheco at gmail.com Sun Jun 22 13:36:10 2008 From: polo.pacheco at gmail.com (Pacheco Paul) Date: Sun, 22 Jun 2008 15:36:10 +0200 Subject: Hug Day - 24 June 2008 In-Reply-To: <20080621224904.GZ7382@murraytwins.com> References: <20080621224904.GZ7382@murraytwins.com> Message-ID: <485E554A.5090605@gmail.com> Brian Murray a écrit : > For the next hug day, on Tuesday, June 24th, we will be doing something > quite different. We generally focus on moving bugs from the New status > to Incomplete or Confirmed, but on the next hug day we'll work on > helping move bugs from Fix Committed to Fix Released! We'll do this by > verifying that packages in the hardy-proposed repository fix the bugs > they were designed to and that the package still functions that way it > should. The list of targeted bugs and tasks is posted at: > > https://wiki.ubuntu.com/UbuntuBugDay/20080624 > > Our goal is to have at least two people test every bug in that list. > > So on 24 June 2008, in all timezones, we'll be meeting in #ubuntu-bugs > on irc.freenode.net for a very special Ubuntu Hug Day. > > https://wiki.ubuntu.com/UbuntuBugDay > > While you are welcome to apply to join the Ubuntu Bug Control team > anytime, Hug Day is a great day to join! > > https://wiki.ubuntu.com/UbuntuBugControl > > If you're interested in helping to make the Hardy Heron release of > Ubuntu even better - please join us. And feel free to ask bdmurray, > sbeattie, pedro, heno and the rest of the team for ways to help out. We > hope to see you there and your name on the list of testers! > > Sincerely, > Sorry too disturbe but, can a 1 year user can help in a way? I am trying to take part in the motu and bugsquad so if you need help on that day I will be on the channel. From pedro at ubuntu.com Tue Jun 24 18:54:46 2008 From: pedro at ubuntu.com (Pedro Villavicencio Garrido) Date: Tue, 24 Jun 2008 14:54:46 -0400 Subject: QA Team Meeting - Jun 25 2008 Message-ID: <1214333686.8715.8.camel@thylacine> Hello Ubuntu Lovers, The Wednesday 25 of June we're going to have our next Ubuntu QA Team Meeting in #ubuntu-meeting at 1700 UTC[1]. The Agenda for the meeting can be found at: https://wiki.ubuntu.com/QATeam/Meetings Please feel free to add items you want do discuss during it. 1- http://fridge.ubuntu.com/node/1509 Best Regards, pedro. From jw+debian at jameswestby.net Wed Jun 25 17:12:24 2008 From: jw+debian at jameswestby.net (James Westby) Date: Wed, 25 Jun 2008 18:12:24 +0100 Subject: Reminder: MOTU School session tomorrow at 10:00 UTC Message-ID: <1214413944.10285.88.camel@flash> Hello again, Tomorrow (26th June) there is going to be a MOTU School session, presented by Emmet Hikory, on "Effectively using and interpreting apport retraces." The session will be at 10:00 UTC in #ubuntu-classroom on irc.freenode.net. Thanks, James From ahmedelhassairi at gmail.com Wed Jun 25 19:53:11 2008 From: ahmedelhassairi at gmail.com (Ahmed Elhassari) Date: Wed, 25 Jun 2008 20:53:11 +0100 Subject: Reminder: MOTU School session tomorrow at 10:00 UTC In-Reply-To: <1214413944.10285.88.camel@flash> References: <1214413944.10285.88.camel@flash> Message-ID: Is this session going to be logged on a wiki page or something as I can be online at that time???? Thanks Ahmed On Wed, Jun 25, 2008 at 6:12 PM, James Westby > wrote: > Hello again, > > Tomorrow (26th June) there is going to be a MOTU School session, > presented by Emmet Hikory, on "Effectively using and interpreting > apport retraces." The session will be at 10:00 UTC in #ubuntu-classroom > on irc.freenode.net. > > Thanks, > > James > > > -- > Ubuntu-motu-mentors mailing list > Ubuntu-motu-mentors at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu-mentors > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at ubuntu.com Wed Jun 25 22:34:51 2008 From: brian at ubuntu.com (Brian Murray) Date: Wed, 25 Jun 2008 15:34:51 -0700 Subject: Bug Importance Guidelines Message-ID: <20080625223451.GL7382@murraytwins.com> The current guidelines[0] for setting bug importance were written at at time when there were not other ways, release targetting and milestones, for identifying the importance of a bug to the distribution as a whole. Subsequently, these guidelines use phrases like 'severe impact on a small portion of Ubuntu users', 'moderate impact on a large portion of Ubuntu users' and 'severe impact on a large portion of Ubuntu users'. Since the release team is actively using milestones combined with release targetting and measuring the quantity of users impacted is vague and subjective - I believe that the importance of a bug should be determined based on the impact for the package affected. This would change the definition of High and Critical and the following is what I have in mind for new guidelines. * '''High''': A bug which fulfills one of the following criteria: * is a reproducible crash report * affects the core functionality of the package * a problem with an essential hardware component (disk controller, laptop built-in wireless, video card, keyboard, mouse) * '''Critical''': A bug which fulfills one of the following criteria: * causes a package fail to install or upgrade * causes a package to fail to build * causes a loss of data * causes a severe memory leak * makes the package unusable e.g. application fails to start or perform its primary function [0] https://wiki.ubuntu.com/Bugs/Importance -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From mpt at canonical.com Thu Jun 26 08:56:39 2008 From: mpt at canonical.com (Matthew Paul Thomas) Date: Thu, 26 Jun 2008 09:56:39 +0100 Subject: Bug Importance Guidelines In-Reply-To: <20080625223451.GL7382@murraytwins.com> References: <20080625223451.GL7382@murraytwins.com> Message-ID: <486359C7.3080808@canonical.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Murray wrote on 25/06/08 23:34: >... > Since the release team is actively using milestones combined with > release targetting and measuring the quantity of users impacted is vague > and subjective - I believe that the importance of a bug should be > determined based on the impact for the package affected. >... Eventually Launchpad is likely to provide statistics and graphs of open bug reports by Importance for Ubuntu as a whole, for help in release management. These will be somewhat misleading if Importance has been measured relative to the individual package, rather than relative to Ubuntu as a whole. For example, a bug that makes a package unusable for some people may be Critical relative to that package, but only High relative to Ubuntu if hardly anyone uses that package. Cheers - -- Matthew Paul Thomas http://mpt.net.nz/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIY1nH6PUxNfU6ecoRAv3yAJ486mGwxiIlsYxMshCrxMAwS7jPcQCfaNZl dvbg/QQk/9Xk6sQTtutvxNk= =8HFs -----END PGP SIGNATURE----- From persia at ubuntu.com Thu Jun 26 09:03:00 2008 From: persia at ubuntu.com (Emmet Hikory) Date: Thu, 26 Jun 2008 18:03:00 +0900 Subject: Bug Importance Guidelines In-Reply-To: <486359C7.3080808@canonical.com> References: <20080625223451.GL7382@murraytwins.com> <486359C7.3080808@canonical.com> Message-ID: <9bd2f8970806260203v70b6a69ene6797d780a4fb3f9@mail.gmail.com> Matthew Paul Thomas wrote: > Brian Murray wrote on 25/06/08 23:34: >>... >> Since the release team is actively using milestones combined with >> release targetting and measuring the quantity of users impacted is vague >> and subjective - I believe that the importance of a bug should be >> determined based on the impact for the package affected. >>... > > Eventually Launchpad is likely to provide statistics and graphs of open > bug reports by Importance for Ubuntu as a whole, for help in release > management. > > These will be somewhat misleading if Importance has been measured > relative to the individual package, rather than relative to Ubuntu as a > whole. For example, a bug that makes a package unusable for some people > may be Critical relative to that package, but only High relative to > Ubuntu if hardly anyone uses that package. Yes, but the current arrangement is very confusing to those working with the bugs. It is not a rare case that a bug with importance "High" does not qualify for SRU, while a bug with importance "Low" does. With the previous model, it was very diffficult to understand what bugs had meaning impact on a given pacakge, requiring anyone looking at a package to carefully review each bug to determine if further action was required. With the transition to the new system, it should be much easier to determine which bugs need attention as stable updates, and which packages are in need of attention (due to being completely broken). Admittedly, this makes the Launchpad statistics and graphs largely useless, but there are existing alternate implementations for statistics and graphs of bugs in Ubuntu that are likely to follow this change, and so maintain the current functionality. -- Emmet HIKORY From jw+debian at jameswestby.net Thu Jun 26 12:13:15 2008 From: jw+debian at jameswestby.net (James Westby) Date: Thu, 26 Jun 2008 13:13:15 +0100 Subject: MOTU School session logs from today available In-Reply-To: <1214413944.10285.88.camel@flash> References: <1214413944.10285.88.camel@flash> Message-ID: <1214482395.10285.132.camel@flash> Hi all, Thanks to Emmet for running the session, it was very informative. Logs are now available for those who were not able to make the session at https://wiki.ubuntu.com/MOTU/School/IntrepretingApportRetraces I was unable to find any wiki documentation about using Apport in triaging and bug fixing. The session was great, but an IRC log is not the best way to present the information, so if anyone would like to turn it in to some documentation your help would be appreciated. Please get in touch if you would like to help. Thanks, James From rjanke at blueyonder.co.uk Thu Jun 26 09:33:41 2008 From: rjanke at blueyonder.co.uk (Ralph Janke) Date: Thu, 26 Jun 2008 10:33:41 +0100 Subject: Bug Importance Guidelines In-Reply-To: <20080625223451.GL7382@murraytwins.com> References: <20080625223451.GL7382@murraytwins.com> Message-ID: <48636275.3080509@blueyonder.co.uk> Brian Murray wrote: > Since the release team is actively using milestones combined with > release targetting and measuring the quantity of users impacted is vague > and subjective - I believe that the importance of a bug should be > determined based on the impact for the package affected. > This is fine for me. Ralph Janke (txwikinger) From mok at bioxray.au.dk Thu Jun 26 16:31:57 2008 From: mok at bioxray.au.dk (Morten Kjeldgaard) Date: Thu, 26 Jun 2008 18:31:57 +0200 Subject: Bug Importance Guidelines In-Reply-To: <486359C7.3080808@canonical.com> References: <20080625223451.GL7382@murraytwins.com> <486359C7.3080808@canonical.com> Message-ID: <97B1F93A-7F31-4F82-916B-615495CBAF23@bioxray.au.dk> On 26/06/2008, at 10.56, Matthew Paul Thomas wrote: > > These will be somewhat misleading if Importance has been measured > relative to the individual package, rather than relative to Ubuntu > as a > whole. For example, a bug that makes a package unusable for some > people > may be Critical relative to that package, but only High relative to > Ubuntu if hardly anyone uses that package. That is true, but if the severity is judged on the package level, it is easy to compute a "distribution" score by summing the severity of bugs for each package, multiplied by a weight factor, which could be the package usage times an "importance" score. Normalize by dividing with the number of packages. Cheers, Morten -- Morten Kjeldgaard mok0 at ubuntu.com From onno at itmaze.com.au Thu Jun 26 22:32:13 2008 From: onno at itmaze.com.au (Onno Benschop) Date: Fri, 27 Jun 2008 06:32:13 +0800 Subject: Bug Importance Guidelines In-Reply-To: <20080625223451.GL7382@murraytwins.com> References: <20080625223451.GL7382@murraytwins.com> Message-ID: <486418ED.1030004@itmaze.com.au> On 26/06/08 06:34, Brian Murray wrote: > [0] https://wiki.ubuntu.com/Bugs/Importance I think it would be useful to include appropriate links on a launchpad bug page to this page (and others like appropriate tags and status). This would ensure continuity and allow bug submitters, bug owners and assignees to be consistent in their allocations. Probably some of the links below should be on the report a bug page: * https://wiki.ubuntu.com/ReportingBugs * https://wiki.ubuntu.com/HelpingWithBugs * https://wiki.ubuntu.com/Bugs/HowToTriage -- Onno Benschop Connected via Optus B3 at S31°54'06" - E115°50'39" (Yokine, WA) -- ()/)/)() ..ASCII for Onno.. |>>? ..EBCDIC for Onno.. --- -. -. --- ..Morse for Onno.. ITmaze - ABN: 56 178 057 063 - ph: 04 1219 8888 - onno at itmaze.com.au From sense at qense.nl Sat Jun 28 09:54:18 2008 From: sense at qense.nl (Sense Hofstede) Date: Sat, 28 Jun 2008 11:54:18 +0200 Subject: Idea: Forwarding Subteam Message-ID: <1214646858.7051.11.camel@nott> As you can see in the list of bugs that need to be forwarded upstream[1] there are a lot of bugs that are still just reported in Launchpad. But this list contains just bugs where someone pressed on +project or +distribution without entering an URL or email address. However, there are loads and loads of bugs that need to be forwarded upstream, but don't have such an empty bugwatch attached to them. When we want to make the bug reports useful, we not only have to triage the bugs correctly, but also make sure that they reach the upstream author. This is a big task and too few people are doing it. What need to be done, according to me, is to create a set of packages that need to be monitored and checked for confirmed and triaged bugs and create some clearer policies(e.g. create bugwatches for all bug reports you can find, including other distributions? How do you write the upstream summary?). A subteam consisting of people dedicated to forwarding upstream and assigned so specific packages(or upstream bug trackers) look out for bugs ready to be reported upstream. What do you think?  [1] http://tinyurl.com/3kjm3p --- Sense Hofstede -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dit berichtdeel is digitaal ondertekend URL: From persia at ubuntu.com Sat Jun 28 13:37:26 2008 From: persia at ubuntu.com (Emmet Hikory) Date: Sat, 28 Jun 2008 22:37:26 +0900 Subject: Idea: Forwarding Subteam In-Reply-To: <1214646858.7051.11.camel@nott> References: <1214646858.7051.11.camel@nott> Message-ID: <9bd2f8970806280637p54989cbek4a79b4b9752c3a1a@mail.gmail.com> On Sat, Jun 28, 2008 at 6:54 PM, Sense Hofstede wrote: > This is a big task and too few people are doing it. What need to be > done, according to me, is to create a set of packages that need to be > monitored and checked for confirmed and triaged bugs and create some > clearer policies(e.g. create bugwatches for all bug reports you can > find, including other distributions? How do you write the upstream > summary?). A subteam consisting of people dedicated to forwarding > upstream and assigned so specific packages(or upstream bug trackers) > look out for bugs ready to be reported upstream. Rather than creating a subteam, and tracking it in LP, and all of that, I'd encourage the simple definition of the work, and the organisation of regular times to meet and coordinate/report current progress. While some people are excited about joining a new team, this feeling rarely lasts. If someone is willing to regularly (e.g. once a fortnight, once a month) organise a drive to meet the goal, finding people willing to participate in the drive is easier, and those who cannot commit to joining every session may well be able to join the occasional session without the stigma of possibly not meeting team requirements. That said, I agree that helping get more upstream is quite possibly useful, and that building better relationships with specific upstreams can have tremendous value in ensuring that the version of the software in Ubuntu is as good as it can be. -- Emmet HIKORY From brian at ubuntu.com Mon Jun 30 22:31:19 2008 From: brian at ubuntu.com (Brian Murray) Date: Mon, 30 Jun 2008 15:31:19 -0700 Subject: Unlinked Bug Watches Message-ID: <20080630223119.GV7382@murraytwins.com> Earlier today I was talking to Sense Hofstede on IRC and he'd asked me about how I came up with the bug day list for April 1st[0]. This was basically a one off query that I ran to find bug reports with an unlinked bug watch. By unlinked I mean an Ubuntu bug report that has a comment referring to an upstream bug tracking system, but no upstream bug task exists for the Ubuntu bug report. This could happen because someone doesn't know how to add a bug watch or they are not positive a bug in another bug tracking system is the same as their bug. Regardless, we are not getting the full benefit of Launchpad (notifications of upstream bug status changes) if the relevant upstream bug report is not added as a bug task. So I wrote a report[1] that lists these bug reports and the bug tracker mentioned in the comment. The report only looks at New, Incomplete, Confirmed and Triaged bugs with bug trackers mentioned in a comment and not added as an upstream task. The report is updated daily. Instead of reading every comment to find the bug watch you can look in the "Remote bug watches" applet on the left hand side of the bug report to determine which bug tracker is mentioned. In the event that remote bug reference is wrong it is possible to remove the watch by clicking on the pencil next to it in the applet and then click "Delete Bug Watch". This will remove it from my report and from https://launchpad.net/bugs/bugtrackers/ . [0] https://wiki.ubuntu.com/UbuntuBugDay/20080401 [1] http://people.ubuntu.com/~brian/reports/database/unlinked-bugwatch.html -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: