From brian at ubuntu.com Mon Mar 2 22:25:59 2009 From: brian at ubuntu.com (Brian Murray) Date: Mon, 2 Mar 2009 14:25:59 -0800 Subject: Printing Bugs Message-ID: <20090302222559.GM7788@murraytwins.com> In the Jaunty version of apport I've added a function, attach_printing(), that will gather the same information as the "printingbuginfo" script[1]. This function is currently utilized by the package-hook for cups[2]. What this means is that if you submit a bug report from Jaunty regarding cups via 'ubuntu-bug cups' a lot of information relevant to debugging the report will be gathered automatically. Additionally, when we are triaging bug reports about cups from users running Jaunty we can ask people to run 'apport-collect BUGNUMBER' and the same information will be gathered. This should make working with cups bug reports significantly easier. I spoke with Till Kamppeter about what other packages would benefit from using this function and he indicated foomatic, ghostscript and printing driver packages. If anybody could help out adding package hooks, they'd look almost the same as [2], for these packages that would be outstanding. [1] https://wiki.ubuntu.com/PrintingBugInfoScript [2] http://bazaar.launchpad.net/~pitti/cups/debian-trunk/annotate/head%3A/debian/local//apport-hook.py Thanks, -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From brian at ubuntu.com Mon Mar 2 23:08:55 2009 From: brian at ubuntu.com (Brian Murray) Date: Mon, 2 Mar 2009 15:08:55 -0800 Subject: Printing Bugs In-Reply-To: <20090302222559.GM7788@murraytwins.com> References: <20090302222559.GM7788@murraytwins.com> Message-ID: <20090302230855.GP7788@murraytwins.com> On Mon, Mar 02, 2009 at 02:25:59PM -0800, Brian Murray wrote: > In the Jaunty version of apport I've added a function, > attach_printing(), that will gather the same information as the > "printingbuginfo" script[1]. This function is currently utilized by the > package-hook for cups[2]. What this means is that if you submit a bug > report from Jaunty regarding cups via 'ubuntu-bug cups' a lot of > information relevant to debugging the report will be gathered > automatically. > > Additionally, when we are triaging bug reports about cups from users > running Jaunty we can ask people to run 'apport-collect BUGNUMBER' and > the same information will be gathered. This should make working with > cups bug reports significantly easier. > > I spoke with Till Kamppeter about what other packages would benefit from > using this function and he indicated foomatic, ghostscript and printing > driver packages. If anybody could help out adding package hooks, they'd > look almost the same as [2], for these packages that would be > outstanding. I meant to include a link to a sample bug report (it is on staging so check it out soon!): https://bugs.staging.launchpad.net/ubuntu/+source/cups/+bug/327450 You'll notice that some information appears in the description, like Lpstat and Papersize and some appears in attachments like PrintingPackages.txt. -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From martinmai1024 at web.de Tue Mar 3 18:52:16 2009 From: martinmai1024 at web.de (Martin Mai) Date: Tue, 03 Mar 2009 19:52:16 +0100 Subject: Announcing the Next Ubuntu Hug Day! - 5th of March, 2009 Message-ID: <1236106336.10513.8.camel@martin-laptop> Fellow Ubuntu Triagers! This week's HugDay target is *drum roll please* flashplugin-nonfree! * 78 New bugs need a hug * 53 Incomplete bugs need a status check * 35 Confirmed bugs need a review Bookmark it, add it to your calendars, turn over those egg-timers! * 5th of March, 2009 * http://wiki.ubuntu.com/UbuntuBugDay/20090305 Can't stress it enough: everyone can help! Have some time? Triage boogz! I won't be upset if you get a headstart~ ;) Have a blog? Blog about Hugday! Have some screen space? Open #ubuntu-bugs and keep an eye out for newcomers in need. Have minions? Teach THEM to triage for you! :) Wanna be famous? Is easy! remember to use 5-A-day so if you do a good work your name could be listed at the top 5-A-Day Contributors in the Ubuntu Hall of Fame page! Make a difference; we will be in #ubuntu-bugs (FreeNode) all day and night, and will be ready to answer your questions about how to help. If you're new to all this, head to http://wiki.ubuntu.com/HelpingWithBugs Have a nice day, Martin Mai [From the BugSquad] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From brian at ubuntu.com Tue Mar 3 23:15:27 2009 From: brian at ubuntu.com (Brian Murray) Date: Tue, 3 Mar 2009 15:15:27 -0800 Subject: Patches in bug reports Message-ID: <20090303231527.GU7788@murraytwins.com> At the UDS for Jaunty there was some discussion about the work flow for bugs with patches and how we can help these bug reports get fixed. As a part of the specification[1] that came out of this discussion I've documented what can be considered a patch and how to work with attachments that are and are not patches[2]. Please take some time to review that page and see how you can help out. Additionally, I've also written a couple of Launchpad reports that may aid in this work flow. There is a report of bug attachments that are flagged as patches[3]. Its a bit different than the standard Launchpad query since it shows you the attachment name and the extension. One thing you could do is sort the table by attachment extension and then look for all the 'conf' extensions and then unflag those patches and educate the reporters about what qualifies as a patch. The other report[4] contains bug reports with attachments that might be patches. The attachment names are searched for the words diff or patch. One thing that you could do with these is to flag the attachment as a patch, if it really is one, and add a comment letting people know about the importance of flagging attachments as patches. However, be careful as sometimes Ubuntu developers[5] forget to check the box too and probably don't need to be reminded of the importance of checking it! [1] https://wiki.ubuntu.com/QATeam/Specs/BugPatchWorkflow [2] https://wiki.ubuntu.com/Bugs/Patches [3] http://qa.ubuntu.com/reports/launchpad-database/unfixed-bugs-with-patches.html [4] http://qa.ubuntu.com/reports/launchpad-database/bugs-with-unmarked-patches.html [5] Who is an Ubuntu developer? The lp_karmasuffix greasemonkey script helps identify them. https://edge.launchpad.net/launchpad-gm-scripts/ Thanks! -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From macoafi at gmail.com Tue Mar 3 22:11:49 2009 From: macoafi at gmail.com (Mackenzie Morgan) Date: Tue, 3 Mar 2009 17:11:49 -0500 Subject: A couple of changes to note Message-ID: <200903031711.52779.macoafi@gmail.com> I just made some changes[1] to the Bugs/Responses wiki page after talking to Brian Murray. Before it said that after 4 weeks of being Incomplete without response, we could invalidate bugs which may actually be completely valid (but we don't have enough info). 4 weeks is long enough for the request-for-info email to stop being on the first page of webmail, and long enough to slip the reporter's mind, but it's not really long enough to constitute abandonment. For this reason, I suggested we make sending reminder comments a more official thing (I know some triagers do this already). If you find a bug with no response after 4+ weeks, please remind the reporter that we're waiting. If, two weeks after the reminder, they still do not respond, then it can be closed ("can", not "must"). The other change I added (didn't talk to Brian about this, but it's not a policy change) is just a hint for triaging. If you install devscripts (that's the package name), you can run "rmadison " to see what versions of a package exist in every released version of Ubuntu ("rmadison -uqa " checks Debian). Compare the version with the one against which the bug was reported. Is it the same? If so, there's no need to ask if the bug has fixed itself. If not, check the changelog and see if the issue was specifically addressed (in which case: Fix Released). [1] https://wiki.ubuntu.com/Bugs/Responses?action=diff&rev2=231&rev1=228 -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo -------------- 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 wolfger at gmail.com Wed Mar 4 10:26:35 2009 From: wolfger at gmail.com (Wolfger) Date: Wed, 4 Mar 2009 05:26:35 -0500 Subject: A couple of changes to note In-Reply-To: <200903031711.52779.macoafi@gmail.com> References: <200903031711.52779.macoafi@gmail.com> Message-ID: <3b00b3330903040226m72fa65fay4fcaf39f3b7153af@mail.gmail.com> On Tue, Mar 3, 2009 at 5:11 PM, Mackenzie Morgan wrote: > If you find a bug with no response after > 4+ weeks, please remind the reporter that we're waiting.  If, two weeks after > the reminder, they still do not respond, then it can be closed ("can", not > "must"). Speaking as somebody who does a lot of invalidating of old bugs, I have to say that responses from the submitter are the exception, not the rule. Maybe (and I'm being generous) 10% of these bugs see life again. So this (proposed?) change only adds to the work load without providing any extra value. Under the 4-weeks-to-dead system, a triager only touches the bug once, and if the bug is still alive, the submitter touches the bug once. Under this new system, triagers will have to touch the bug twice if they are dead (don't play with dead bugs!), but the process for it's-not-dead-yet bugs hasn't actually changed at all. -- Wolfger http://wolfger.wordpress.com/ http://twitter.com/wolfger http://identi.ca/wolfger The world is a mess, and I just... need to rule it. From macoafi at gmail.com Wed Mar 4 11:53:44 2009 From: macoafi at gmail.com (Mackenzie Morgan) Date: Wed, 4 Mar 2009 06:53:44 -0500 Subject: A couple of changes to note In-Reply-To: <3b00b3330903040226m72fa65fay4fcaf39f3b7153af@mail.gmail.com> References: <200903031711.52779.macoafi@gmail.com> <3b00b3330903040226m72fa65fay4fcaf39f3b7153af@mail.gmail.com> Message-ID: <200903040653.49253.macoafi@gmail.com> On Wednesday 04 March 2009 5:26:35 am Wolfger wrote: > Speaking as somebody who does a lot of invalidating of old bugs, I > have to say that responses from the submitter are the exception, not > the rule. Maybe (and I'm being generous) 10% of these bugs see life > again. So this (proposed?) change only adds to the work load without > providing any extra value. Under the 4-weeks-to-dead system, a triager > only touches the bug once, and if the bug is still alive, the > submitter touches the bug once. Under this new system, triagers will > have to touch the bug twice if they are dead (don't play with dead > bugs!), but the process for it's-not-dead-yet bugs hasn't actually > changed at all. Leaving a bug which has not had a response alone, in incomplete-without- response mode does not hurt anything. They don't *need* to be closed. Prompting the user to supply more of the needed input can be good. Going through the list of bugs last touched 28 days ago and killing them makes reporters feel ignored. The bugs aren't dead til you invalidate them. Someone that can reproduce it can supply the needed input. Once you invalidate, it goes off everyone's radar and stops showing up in bug searches, so people who can reproduce have to go through submitting a whole new bug when they could've just added the one missing piece of information to the original. Triaging's not about closing as many bugs as possible. It's about improving bug reports. You could say "resolving" bugs, but "nevermind we don't want to deal with you because you're not prompt enough" isn't really a resolution. -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo -------------- 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 wolfger at gmail.com Wed Mar 4 13:32:30 2009 From: wolfger at gmail.com (Wolfger) Date: Wed, 4 Mar 2009 08:32:30 -0500 Subject: A couple of changes to note In-Reply-To: <200903040653.49253.macoafi@gmail.com> References: <200903031711.52779.macoafi@gmail.com> <3b00b3330903040226m72fa65fay4fcaf39f3b7153af@mail.gmail.com> <200903040653.49253.macoafi@gmail.com> Message-ID: <3b00b3330903040532g3729ddf5pa91d4fe48a72a742@mail.gmail.com> On Wed, Mar 4, 2009 at 6:53 AM, Mackenzie Morgan wrote: > Leaving a bug which has not had a response alone, in incomplete-without- > response mode does not hurt anything.  They don't *need* to be closed. > Prompting the user to supply more of the needed input can be good.  Going > through the list of bugs last touched 28 days ago and killing them makes > reporters feel ignored. The bugs aren't dead til you invalidate them.  Someone > that can reproduce it can supply the needed input.  Once you invalidate, it > goes off everyone's radar and stops showing up in bug searches, so people who > can reproduce have to go through submitting a whole new bug when they could've > just added the one missing piece of information to the original. OK, I can see your point, but that really only applies if you're talking about never invalidating incomplete bugs at all. The new system you mentioned merely adds two weeks of life. Many of the old incompletes I invalidate have been untouched for upwards of 2 months (more than double the 28 days) already. 5 months or more is not uncommon. I've closed bugs that were idle for a year and filed against distros that are now unsupported. I also don't see how "you never responded, so I'm closing your bug" can make anybody feel ignored. They, after all, were the ones doing the ignoring. Mostly I get responses (when I get responses) like "thank you. I forgot about this bug. It's no longer a problem for me." or "Sorry, I missed the request for info. Here it is." -- Wolfger http://wolfger.wordpress.com/ http://twitter.com/wolfger http://identi.ca/wolfger The world is a mess, and I just... need to rule it. From memsize at videotron.ca Wed Mar 4 18:56:52 2009 From: memsize at videotron.ca (Gaetan Nadon) Date: Wed, 04 Mar 2009 13:56:52 -0500 Subject: A couple of changes to note In-Reply-To: <200903040653.49253.macoafi@gmail.com> References: <200903031711.52779.macoafi@gmail.com> <3b00b3330903040226m72fa65fay4fcaf39f3b7153af@mail.gmail.com> <200903040653.49253.macoafi@gmail.com> Message-ID: <1236193012.9006.11.camel@ubuntu> Hi, Can you explain how this policy fits/integrates with the https://help.launchpad.net/BugExpiry automated process which "expires" bug reports after 60 days when some conditions are met? ========================================================== Launchpad will mark bugs as candidates for expiry if it appears that they have been abandoned. To determine if a bug has been abandoned, Launchpad uses the following conditions: * it has the "Incomplete" status * the last update was more than 60 days ago * it is not marked as a duplicate of another bug (duplicate bugs have no status of their own and so aren't expirable). * it has not been assigned to anyone * it is not targeted to a milestone. Only projects and distributions that use Launchpad as their bug tracker and that have not disabled bug expiry are part of the bug expiration process. ============================================================ For example, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/85796 was marked for expiry yesterday, however there is no observable change to the bug report I can detect. How does one list "expired" bug reports? Thanks On Wed, 2009-03-04 at 06:53 -0500, Mackenzie Morgan wrote: > On Wednesday 04 March 2009 5:26:35 am Wolfger wrote: > > Speaking as somebody who does a lot of invalidating of old bugs, I > > have to say that responses from the submitter are the exception, not > > the rule. Maybe (and I'm being generous) 10% of these bugs see life > > again. So this (proposed?) change only adds to the work load without > > providing any extra value. Under the 4-weeks-to-dead system, a triager > > only touches the bug once, and if the bug is still alive, the > > submitter touches the bug once. Under this new system, triagers will > > have to touch the bug twice if they are dead (don't play with dead > > bugs!), but the process for it's-not-dead-yet bugs hasn't actually > > changed at all. > > Leaving a bug which has not had a response alone, in incomplete-without- > response mode does not hurt anything. They don't *need* to be closed. > Prompting the user to supply more of the needed input can be good. Going > through the list of bugs last touched 28 days ago and killing them makes > reporters feel ignored. The bugs aren't dead til you invalidate them. Someone > that can reproduce it can supply the needed input. Once you invalidate, it > goes off everyone's radar and stops showing up in bug searches, so people who > can reproduce have to go through submitting a whole new bug when they could've > just added the one missing piece of information to the original. > > Triaging's not about closing as many bugs as possible. It's about improving > bug reports. You could say "resolving" bugs, but "nevermind we don't want to > deal with you because you're not prompt enough" isn't really a resolution. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.grossmeier at gmail.com Wed Mar 4 20:48:52 2009 From: greg.grossmeier at gmail.com (Greg Grossmeier) Date: Wed, 4 Mar 2009 15:48:52 -0500 Subject: A couple of changes to note In-Reply-To: <1236193012.9006.11.camel@ubuntu> References: <200903031711.52779.macoafi@gmail.com> <3b00b3330903040226m72fa65fay4fcaf39f3b7153af@mail.gmail.com> <200903040653.49253.macoafi@gmail.com> <1236193012.9006.11.camel@ubuntu> Message-ID: There was a decision made to not actually mark "expired" bugs as invalid as, I believe, there was some vocal opposition to it. So Ubuntu has been one of the projects to "[disable] bug expiry are part of the bug expiration process." This page [0] will list all bugs that are 'expirable' and is linked to from the main Ubuntu bugs page on Launchpad. Best, Greg [0] https://bugs.edge.launchpad.net/ubuntu/+expirable-bugs On Wed, Mar 4, 2009 at 1:56 PM, Gaetan Nadon wrote: > Hi, > > Can you explain how this policy fits/integrates with the > https://help.launchpad.net/BugExpiry automated process which "expires" bug > reports after 60 days when some conditions are met? > > ========================================================== > Launchpad will mark bugs as candidates for expiry if it appears that they > have been abandoned. To determine if a bug has been abandoned, Launchpad > uses the following conditions: > > it has the "Incomplete" status > the last update was more than 60 days ago > it is not marked as a duplicate of another bug (duplicate bugs have no > status of their own and so aren't expirable). > it has not been assigned to anyone > it is not targeted to a milestone. > > Only projects and distributions that use Launchpad as their bug tracker and > that have not disabled bug expiry are part of the bug expiration process. > ============================================================ > > For example, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/85796 > was marked for expiry yesterday, however there is no observable change to > the bug report I can detect. How does one list "expired" bug reports? > > Thanks > > On Wed, 2009-03-04 at 06:53 -0500, Mackenzie Morgan wrote: > > On Wednesday 04 March 2009 5:26:35 am Wolfger wrote: >> Speaking as somebody who does a lot of invalidating of old bugs, I >> have to say that responses from the submitter are the exception, not >> the rule. Maybe (and I'm being generous) 10% of these bugs see life >> again. So this (proposed?) change only adds to the work load without >> providing any extra value. Under the 4-weeks-to-dead system, a triager >> only touches the bug once, and if the bug is still alive, the >> submitter touches the bug once. Under this new system, triagers will >> have to touch the bug twice if they are dead (don't play with dead >> bugs!), but the process for it's-not-dead-yet bugs hasn't actually >> changed at all. > > Leaving a bug which has not had a response alone, in incomplete-without- > response mode does not hurt anything. They don't *need* to be closed. > Prompting the user to supply more of the needed input can be good. Going > through the list of bugs last touched 28 days ago and killing them makes > reporters feel ignored. The bugs aren't dead til you invalidate them. > Someone > that can reproduce it can supply the needed input. Once you invalidate, it > goes off everyone's radar and stops showing up in bug searches, so people > who > can reproduce have to go through submitting a whole new bug when they > could've > just added the one missing piece of information to the original. > > Triaging's not about closing as many bugs as possible. It's about improving > bug reports. You could say "resolving" bugs, but "nevermind we don't want > to > deal with you because you're not prompt enough" isn't really a resolution. > > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > From macoafi at gmail.com Wed Mar 4 20:54:52 2009 From: macoafi at gmail.com (Mackenzie Morgan) Date: Wed, 4 Mar 2009 15:54:52 -0500 Subject: A couple of changes to note In-Reply-To: <37428-SnapperMsgD8DB99B6C5D42E56@[70.211.112.158]> References: <200903031711.52779.macoafi@gmail.com> <200903040653.49253.macoafi@gmail.com> <37428-SnapperMsgD8DB99B6C5D42E56@[70.211.112.158]> Message-ID: <200903041554.55571.macoafi@gmail.com> On Wednesday 04 March 2009 8:08:31 am Scott Kitterman wrote: > On Wed, 4 Mar 2009 06:53:44 -0500 Mackenzie Morgan > wrote: > >On Wednesday 04 March 2009 5:26:35 am Wolfger wrote: > >> Speaking as somebody who does a lot of invalidating of old bugs, I > >> have to say that responses from the submitter are the exception, not > >> the rule. Maybe (and I'm being generous) 10% of these bugs see life > >> again. So this (proposed?) change only adds to the work load without > >> providing any extra value. Under the 4-weeks-to-dead system, a triager > >> only touches the bug once, and if the bug is still alive, the > >> submitter touches the bug once. Under this new system, triagers will > >> have to touch the bug twice if they are dead (don't play with dead > >> bugs!), but the process for it's-not-dead-yet bugs hasn't actually > >> changed at all. > > > >Leaving a bug which has not had a response alone, in incomplete-without- > >response mode does not hurt anything. They don't *need* to be closed. > >Prompting the user to supply more of the needed input can be good. Going > >through the list of bugs last touched 28 days ago and killing them makes > >reporters feel ignored. The bugs aren't dead til you invalidate them. > Someone > >that can reproduce it can supply the needed input. Once you invalidate, > it > >goes off everyone's radar and stops showing up in bug searches, so people > who > >can reproduce have to go through submitting a whole new bug when they > could've > >just added the one missing piece of information to the original. > > > >Triaging's not about closing as many bugs as possible. It's about > improving > >bug reports. You could say "resolving" bugs, but "nevermind we don't want > to > >deal with you because you're not prompt enough" isn't really a resolution. > > > I missed the start of this thread (I guess it just spilled over from -bugs > to -qa). I'm curious what change is being proposed. > > I generally echo what Mackenzie is saying. I'd add that Launchpad has an > auto-expire feature that Ubuntu should use if it wants bugs to expire after > a certain period of no reply. If the project has chosen not to use it/have > a longer timeout, then I don't think triagers should feel obligated to fill > the gap. It was in use. A lot of bug reporters and developers were very *not happy* when bugs were automatically closed by the system en masse. -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo -------------- 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 greg.grossmeier at gmail.com Wed Mar 4 21:34:55 2009 From: greg.grossmeier at gmail.com (Greg Grossmeier) Date: Wed, 4 Mar 2009 16:34:55 -0500 Subject: A couple of changes to note In-Reply-To: <37755-SnapperMsgD8DB99B6C5D4A267@75.222.218.95> References: <200903031711.52779.macoafi@gmail.com> <3b00b3330903040226m72fa65fay4fcaf39f3b7153af@mail.gmail.com> <200903040653.49253.macoafi@gmail.com> <1236193012.9006.11.camel@ubuntu> <37755-SnapperMsgD8DB99B6C5D4A267@75.222.218.95> Message-ID: On Wed, Mar 4, 2009 at 4:25 PM, Scott Kitterman wrote: > On Wed, 4 Mar 2009 15:48:52 -0500 Greg Grossmeier > wrote: >>There was a decision made to not actually mark "expired" bugs as >>invalid as, I believe, there was some vocal opposition to it.  So >>Ubuntu has been one of the projects to "[disable] bug expiry are part >>of the bug expiration process." >> >>This page [0] will list all bugs that are 'expirable' and is linked to >>from the main Ubuntu bugs page on Launchpad. >> > Given that Ubuntu has already decided it doesn't want bugs to automatically > be invalidated after a period of time, the notion that triagers should > automatically mark bugs invalid after a set period of time seems odd to me. I agree. And because I agree, I would personally like this whole 'work flow' to be automated. If a bug is expirable according to current requirements, have Launchpad Janitor post a "hey, this is old and untouched and incomplete, please respond," then wait the two weeks, then invalidate. Yes, I am advocating to re-enable the auto-expiry feature of Launchpad. As I believe that the percentage of incorrectly invalidated reports by a system like this will be low (I have no evidence for this, just a gut feeling), simply having a page that lists reports that have comments made to them AFTER Launchpad Janitor auto-expired them _should_ be enough to not lose valid reports. Of course, this is beyond the scope of the current topic, which is adding the extra step in invalidating bugs, which I am ok with. Best, Greg From brian at ubuntu.com Wed Mar 4 21:40:35 2009 From: brian at ubuntu.com (Brian Murray) Date: Wed, 4 Mar 2009 13:40:35 -0800 Subject: A couple of changes to note In-Reply-To: <200903041554.55571.macoafi@gmail.com> References: <200903031711.52779.macoafi@gmail.com> <200903040653.49253.macoafi@gmail.com> <37428-SnapperMsgD8DB99B6C5D42E56@[70.211.112.158]> <200903041554.55571.macoafi@gmail.com> Message-ID: <20090304214035.GZ7788@murraytwins.com> On Wed, Mar 04, 2009 at 03:54:52PM -0500, Mackenzie Morgan wrote: > On Wednesday 04 March 2009 8:08:31 am Scott Kitterman wrote: > > On Wed, 4 Mar 2009 06:53:44 -0500 Mackenzie Morgan > > wrote: > > >On Wednesday 04 March 2009 5:26:35 am Wolfger wrote: > > >> Speaking as somebody who does a lot of invalidating of old bugs, I > > >> have to say that responses from the submitter are the exception, not > > >> the rule. Maybe (and I'm being generous) 10% of these bugs see life > > >> again. So this (proposed?) change only adds to the work load without > > >> providing any extra value. Under the 4-weeks-to-dead system, a triager > > >> only touches the bug once, and if the bug is still alive, the > > >> submitter touches the bug once. Under this new system, triagers will > > >> have to touch the bug twice if they are dead (don't play with dead > > >> bugs!), but the process for it's-not-dead-yet bugs hasn't actually > > >> changed at all. > > > > > >Leaving a bug which has not had a response alone, in incomplete-without- > > >response mode does not hurt anything. They don't *need* to be closed. > > >Prompting the user to supply more of the needed input can be good. Going > > >through the list of bugs last touched 28 days ago and killing them makes > > >reporters feel ignored. The bugs aren't dead til you invalidate them. > > Someone > > >that can reproduce it can supply the needed input. Once you invalidate, > > it > > >goes off everyone's radar and stops showing up in bug searches, so people > > who > > >can reproduce have to go through submitting a whole new bug when they > > could've > > >just added the one missing piece of information to the original. > > > > > >Triaging's not about closing as many bugs as possible. It's about > > improving > > >bug reports. You could say "resolving" bugs, but "nevermind we don't want > > to > > >deal with you because you're not prompt enough" isn't really a resolution. > > > > > I missed the start of this thread (I guess it just spilled over from -bugs > > to -qa). I'm curious what change is being proposed. > > > > I generally echo what Mackenzie is saying. I'd add that Launchpad has an > > auto-expire feature that Ubuntu should use if it wants bugs to expire after > > a certain period of no reply. If the project has chosen not to use it/have > > a longer timeout, then I don't think triagers should feel obligated to fill > > the gap. > > It was in use. A lot of bug reporters and developers were very *not happy* > when bugs were automatically closed by the system en masse. Some of this was also due to the fact that not all the rules for expiration were correct. -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From wolfger at gmail.com Wed Mar 4 22:00:51 2009 From: wolfger at gmail.com (Wolfger) Date: Wed, 4 Mar 2009 17:00:51 -0500 Subject: A couple of changes to note In-Reply-To: References: <200903031711.52779.macoafi@gmail.com> <3b00b3330903040226m72fa65fay4fcaf39f3b7153af@mail.gmail.com> <200903040653.49253.macoafi@gmail.com> <1236193012.9006.11.camel@ubuntu> <37755-SnapperMsgD8DB99B6C5D4A267@75.222.218.95> Message-ID: <3b00b3330903041400j30521d5aj43584e19d40a448b@mail.gmail.com> On Wed, Mar 4, 2009 at 4:34 PM, Greg Grossmeier wrote: > I agree.  And because I agree, I would personally like this whole > 'work flow' to be automated.  If a bug is expirable according to > current requirements, have Launchpad Janitor post a "hey, this is old > and untouched and incomplete, please respond," then wait the two > weeks, then invalidate. I'm OK with that. > Yes, I am advocating to re-enable the auto-expiry feature of > Launchpad.  As I believe that the percentage of incorrectly > invalidated reports by a system like this will be low (I have no > evidence for this, just a gut feeling), simply having a page that > lists reports that have comments made to them AFTER Launchpad Janitor > auto-expired them _should_ be enough to not lose valid reports. The one big problem I see with this is the subgroups (Mozilla team is prominent in my mind) that deviate from the standard Ubuntu rules for bug status. Or course, if they could just assign their bugs to somebody, and that would alleviate the problem. > Of course, this is beyond the scope of the current topic, which is > adding the extra step in invalidating bugs, which I am ok with. I'm OK with it if it's automated, I oppose it if it adds extra work to the already insufficient workforce. -- Wolfger http://wolfger.wordpress.com/ http://twitter.com/wolfger http://identi.ca/wolfger The world is a mess, and I just... need to rule it. From henrik at canonical.com Thu Mar 5 11:01:55 2009 From: henrik at canonical.com (Henrik Nilsen Omma) Date: Thu, 05 Mar 2009 11:01:55 +0000 Subject: A reminder to use the regression tags Message-ID: <49AFB123.40009@canonical.com> As we approach release it's esp. important to catch potential regressions as they make for a particularly bad user experience. We have a pretty good system now for flagging and escalating them on to the developers [1][2] but I want to spread the word about actually using the tags in every-day triage. When you read a bug please keep in mind whether it may represent a regression and tag it accordingly. Thanks! Btw, I've just added a regression section to HowToTriage. Henrik [1] https://wiki.ubuntu.com/QATeam/RegressionTracking [2] http://qa.ubuntu.com/reports/regression/regression_tracker.html From thekorn at gmx.de Thu Mar 5 11:48:17 2009 From: thekorn at gmx.de (markus korn) Date: Thu, 5 Mar 2009 12:48:17 +0100 Subject: A reminder to use the regression tags In-Reply-To: <49AFB123.40009@canonical.com> References: <49AFB123.40009@canonical.com> Message-ID: <7533d3600903050348k30e6f279s24eaaa4c00d6011@mail.gmail.com> On Thu, Mar 5, 2009 at 12:01 PM, Henrik Nilsen Omma wrote: > We have a pretty good system now for flagging and escalating them on to > the developers [1][2] but I want to spread the word about actually using > the tags in every-day triage. When you read a bug please keep in mind > whether it may represent a regression and tag it accordingly. What do you think about adding a separate "regression testing" section to [0], with small description of each tag and links to [1]/[2]. Bugs/Tags also has some other 'regression*' tags like 'regression' or 'regression-retracer', can they be removed or should they be added to the QATeam/RegressionTracking page? Markus [0] https://wiki.ubuntu.com/Bugs/Tags [1] https://wiki.ubuntu.com/QATeam/RegressionTracking [2] http://qa.ubuntu.com/reports/regression/regression_tracker.html From azimout at gmail.com Thu Mar 5 12:20:14 2009 From: azimout at gmail.com (Dimitris Symeonidis) Date: Thu, 5 Mar 2009 13:20:14 +0100 Subject: A couple of changes to note Message-ID: <36265bc20903050420r15910181l244f067f747e2ec9@mail.gmail.com> Regarding the automated reminder and closing of bugs, I think you are missing one parameter: In your thought process, you're assuming that bugs marked for expiry are correctly marked so, in the sense that the reporter(s) were asked to provide extra info and did not respond. However, from my experience, a small but not ignorable percentage (maybe in the order of 10%???) of these bugs are wrongly marked as such: a) the reporter provided the info requested, but no one ever changed the status back to new/confirmed b) the reporter was asked to try with the latest ubuntu, and has reported that the issue has been resolved, but no one ever changed the status to fix released It would make us look rather silly if in all these cases we start asking "please provide the info requested"... Also, in any decision about closing or leaving open as incomplete, please take into account how this affects the bug statistics we are measuring (Daniel Holbach) Just my €0.02 Dimitris Symeonidis "If you think you're too small to make a difference, try sleeping with a mosquito!" - Amnesty International From wolfger at gmail.com Thu Mar 5 13:25:50 2009 From: wolfger at gmail.com (Wolfger) Date: Thu, 5 Mar 2009 08:25:50 -0500 Subject: automated bug closure Message-ID: <3b00b3330903050525g7d476aefpb32aca154cccabf0@mail.gmail.com> On Thu, Mar 5, 2009 at 7:20 AM, Dimitris Symeonidis wrote: > Regarding the automated reminder and closing of bugs, I think you are > missing one parameter: In your thought process, you're assuming that > bugs marked for expiry are correctly marked so, in the sense that the > reporter(s) were asked to provide extra info and did not respond. > > However, from my experience, a small but not ignorable percentage > (maybe in the order of 10%???) of these bugs are wrongly marked as > such: > a) the reporter provided the info requested, but no one ever changed > the status back to new/confirmed > b) the reporter was asked to try with the latest ubuntu, and has > reported that the issue has been resolved, but no one ever changed the > status to fix released I would also add a case: c) The submitter of the bug incorrectly changes his own bug status to incomplete (presumably because it isn't fixed yet). I've actually seen this about a half dozen times. These are the valid bugs that triagers can save but automated systems will discard (and can give bug submitters a bad impression of Ubuntu, rather than educate them about proper bug filing). -- Wolfger http://wolfger.wordpress.com/ http://twitter.com/wolfger http://identi.ca/wolfger The world is a mess, and I just... need to rule it. From macoafi at gmail.com Thu Mar 5 16:46:48 2009 From: macoafi at gmail.com (Mackenzie Morgan) Date: Thu, 5 Mar 2009 11:46:48 -0500 Subject: automated bug closure In-Reply-To: <3b00b3330903050525g7d476aefpb32aca154cccabf0@mail.gmail.com> References: <3b00b3330903050525g7d476aefpb32aca154cccabf0@mail.gmail.com> Message-ID: <200903051146.48855.macoafi@gmail.com> On Thursday 05 March 2009 8:25:50 am Wolfger wrote: > On Thu, Mar 5, 2009 at 7:20 AM, Dimitris Symeonidis wrote: > > Regarding the automated reminder and closing of bugs, I think you are > > missing one parameter: In your thought process, you're assuming that > > bugs marked for expiry are correctly marked so, in the sense that the > > reporter(s) were asked to provide extra info and did not respond. > > > > However, from my experience, a small but not ignorable percentage > > (maybe in the order of 10%???) of these bugs are wrongly marked as > > such: > > a) the reporter provided the info requested, but no one ever changed > > the status back to new/confirmed > > b) the reporter was asked to try with the latest ubuntu, and has > > reported that the issue has been resolved, but no one ever changed the > > status to fix released > > I would also add a case: > c) The submitter of the bug incorrectly changes his own bug status to > incomplete (presumably because it isn't fixed yet). I've actually seen > this about a half dozen times. These are the valid bugs that triagers > can save but automated systems will discard (and can give bug > submitters a bad impression of Ubuntu, rather than educate them about > proper bug filing). d. Triagers who mark bugs "incomplete" because they don't have enough information but then don't ask any questions. -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo -------------- 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 andres.mujica at seaq.com.co Thu Mar 5 18:38:44 2009 From: andres.mujica at seaq.com.co (Andres Mauricio Mujica Zalamea) Date: Thu, 05 Mar 2009 13:38:44 -0500 Subject: Ubuntu-bugsquad Digest, Vol 33, Issue 2 In-Reply-To: References: Message-ID: <1236278324.11482.79.camel@tecnica.seaq.intranet> Hi > Triaging's not about closing as many bugs as possible. It's about improving > bug reports. You could say "resolving" bugs, but "nevermind we don't want to > deal with you because you're not prompt enough" isn't really a resolution. > please take into account the Collin's post some days ago http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2009/03/02#2009-02-27-bug-triage-rants some aparts from the post: "... >My biggest single annoyance with bug triage is people coming around and asking if bugs are still valid when they haven't put any effort into reproducing them themselves. This annoys bug >submitters too; every so often somebody replies and says "didn't you even bother to check?". This gives a very bad impression of us as a project - wouldn't it be better if we looked as if we knew >what we were talking about? .." also : >Closing a bug is taking an item off somebody's to-do list. in fact just noticed a new report from him about the issue... gonna read it. http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2009/03/05#2009-03-05-bug-triage-redux Anyway i do agree with maco and find a lot of reasons in Collin's post that i believe we should discuss and maybe adopt. regards, --- Andrés Mauricio Mujica Zalamea andres.mujica at seaq.com.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at ubuntu.com Thu Mar 5 21:48:46 2009 From: brian at ubuntu.com (Brian Murray) Date: Thu, 5 Mar 2009 13:48:46 -0800 Subject: Printing Bugs In-Reply-To: <20090302222559.GM7788@murraytwins.com> References: <20090302222559.GM7788@murraytwins.com> Message-ID: <20090305214846.GA15448@murraytwins.com> On Mon, Mar 02, 2009 at 02:25:59PM -0800, Brian Murray wrote: > In the Jaunty version of apport I've added a function, > attach_printing(), that will gather the same information as the > "printingbuginfo" script[1]. This function is currently utilized by the > package-hook for cups[2]. What this means is that if you submit a bug > report from Jaunty regarding cups via 'ubuntu-bug cups' a lot of > information relevant to debugging the report will be gathered > automatically. > > Additionally, when we are triaging bug reports about cups from users > running Jaunty we can ask people to run 'apport-collect BUGNUMBER' and > the same information will be gathered. This should make working with > cups bug reports significantly easier. > > I spoke with Till Kamppeter about what other packages would benefit from > using this function and he indicated foomatic, ghostscript and printing > driver packages. If anybody could help out adding package hooks, they'd > look almost the same as [2], for these packages that would be > outstanding. Steve Beattie was asking about whether or not system-config-printer would benefit from a package hook (it would!) so to help clarify and track things I've opened bug 338442[1]. It has multiple tasks open for each package, that I know of, that could use an apport package hook like the cups one. [1] http://launchpad.net/bugs/338442 -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From brian at ubuntu.com Fri Mar 6 00:12:29 2009 From: brian at ubuntu.com (Brian Murray) Date: Thu, 5 Mar 2009 16:12:29 -0800 Subject: A reminder to use the regression tags In-Reply-To: <7533d3600903050348k30e6f279s24eaaa4c00d6011@mail.gmail.com> References: <49AFB123.40009@canonical.com> <7533d3600903050348k30e6f279s24eaaa4c00d6011@mail.gmail.com> Message-ID: <20090306001229.GJ7788@murraytwins.com> On Thu, Mar 05, 2009 at 12:48:17PM +0100, Markus Korn wrote: > On Thu, Mar 5, 2009 at 12:01 PM, Henrik Nilsen Omma > wrote: > > We have a pretty good system now for flagging and escalating them on to > > the developers [1][2] but I want to spread the word about actually using > > the tags in every-day triage. When you read a bug please keep in mind > > whether it may represent a regression and tag it accordingly. > What do you think about adding a separate "regression testing" section > to [0], with small description of each tag and links to [1]/[2]. > Bugs/Tags also has some other 'regression*' tags like 'regression' or > 'regression-retracer', can they be removed or should they be added to > the QATeam/RegressionTracking page? It looks like Henrik added this to the Bugs/Tags page as per your suggestion. -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From cjk at teamcharliesangels.com Fri Mar 6 13:20:30 2009 From: cjk at teamcharliesangels.com (Charlie Kravetz) Date: Fri, 6 Mar 2009 06:20:30 -0700 Subject: Bugs Reported Against a PPA Message-ID: <20090306062030.0b73f1f6@teamcharliesangels.com> It has been brought up that we currently have no policy in place for bugs reported against a Personal Package Archive(PPA) in launchpad. The majority of bug reporters are attempting to help improve Ubuntu. Without the use of PPA, the distribution loses valuable testing and improvements. As a team, we do not have the resources to determine that the reporter was not sent to the PPA file to test an improvement. The PPA is not an authorized Ubuntu repository, however, no bug should be invalid simply because it was reported against a PPA. I have seen several developers on IRC and in launchpad request users test a package in their PPA. If that package works, it may go on to be placed in the distribution. My opinion: Bugs against a PPA should not be invalid bugs. They should be clearly identified as part of bug triage as being against a PPA, and the PPA owner should have a chance to decide what to do with the bug. This could be easily accomplished by adding a PPA tag to the bugs, and/or add [PPA] to the summary. Perhaps a better procedure that tags would be to create a package for the PPA. As bug reporters will not normally have the knowledge to create that package, it will become the job of the triage team. That involves more work for a team with enough work already. Myself, as QA leader for Xubuntu, have requested individuals to subscribe me to bugs they report when using Xfce 4.6 from a PPA. Hopefully, I will be able to upstream their bug to the developer before it becomes invalid by a well meaning bug triager. What do others think of a policy for these bug reports? Do you have opinions/comments/questions on this? -- Charlie Kravetz Linux Registered User Number 425914 [http://counter.li.org/] Never let anyone steal your DREAM. [http://keepingdreams.com] From hggdh2 at gmail.com Fri Mar 6 14:14:47 2009 From: hggdh2 at gmail.com (hggdh) Date: Fri, 6 Mar 2009 08:14:47 -0600 Subject: Bugs Reported Against a PPA In-Reply-To: <20090306062030.0b73f1f6@teamcharliesangels.com> References: <20090306062030.0b73f1f6@teamcharliesangels.com> Message-ID: <20090306081447.695d74a4@xango2> On Fri, 6 Mar 2009 06:20:30 -0700 Charlie Kravetz wrote: > My opinion: > > Bugs against a PPA should not be invalid bugs. Absolutely. They *are*, after all, bugs. They are just *not* bugs against the official distribution. Yet. > They should be clearly > identified as part of bug triage as being against a PPA, and the PPA > owner should have a chance to decide what to do with the bug. This > could be easily accomplished by adding a PPA tag to the bugs, and/or > add [PPA] to the summary. > > Perhaps a better procedure that tags would be to create a package for > the PPA. As bug reporters will not normally have the knowledge to > create that package, it will become the job of the triage team. That > involves more work for a team with enough work already. Probably the best would be to have Malone adapted to provide a new origin field, or adapt the Project field to allow for assigning to PPAs. > Myself, as QA leader for Xubuntu, have requested individuals to > subscribe me to bugs they report when using Xfce 4.6 from a PPA. > Hopefully, I will be able to upstream their bug to the developer > before it becomes invalid by a well meaning bug triager. I myself have used PPAs to test upstream fixes against Evolution. The feedback from these tests helped upstream on fine-tuning the fixes, with a clear gain to all. Without doubts, +1 on this. Canonical/Ubuntu made a fantastic decision on funding the builder machines; it just does not make sense to have them available, and not provide the PPA packagers with a venue to work on, and resolve, the eventual bugs against their packages. But I really think the Malone folks should be involved here. I am also unaware of an easy way to search on packages provided by PPAs. Thank you for raising the issue, Charlie. Cheers, ..hggdh.. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From wolfger at gmail.com Fri Mar 6 14:47:35 2009 From: wolfger at gmail.com (Wolfger) Date: Fri, 6 Mar 2009 09:47:35 -0500 Subject: Bugs Reported Against a PPA In-Reply-To: <20090306081447.695d74a4@xango2> References: <20090306062030.0b73f1f6@teamcharliesangels.com> <20090306081447.695d74a4@xango2> Message-ID: <3b00b3330903060647w3052e6e5p99fc4ce70add8e0e@mail.gmail.com> On Fri, Mar 6, 2009 at 9:14 AM, hggdh wrote: > Probably the best would be to have Malone adapted to provide a new > origin field, or adapt the Project field to allow for assigning to PPAs. Absolutely! I am 100% behind the "allow for assigning to PPAs" idea. I was thinking the other day that it sucked I couldn't file a bug against a package because I was using a PPA and not an official package... Sadly, I couldn't follow it through to this conclusion. Thanks, Charlie! -- Wolfger http://wolfger.wordpress.com/ http://twitter.com/wolfger http://identi.ca/wolfger The world is a mess, and I just... need to rule it. From laserjock at ubuntu.com Fri Mar 6 16:55:41 2009 From: laserjock at ubuntu.com (Jordan Mantha) Date: Fri, 6 Mar 2009 08:55:41 -0800 Subject: Bugs Reported Against a PPA In-Reply-To: <20090306062030.0b73f1f6@teamcharliesangels.com> References: <20090306062030.0b73f1f6@teamcharliesangels.com> Message-ID: <82926f0e0903060855u337cbe55m558e59be607a2d33@mail.gmail.com> On Fri, Mar 6, 2009 at 5:20 AM, Charlie Kravetz wrote: > It has been brought up that we currently have no policy in place for > bugs reported against a Personal Package Archive(PPA) in launchpad. I believe at least the MOTUs policy has been "don't file bugs about PPA packages in Ubuntu's bug tracker unless specifically told to do so". > The majority of bug reporters are attempting to help improve Ubuntu. > Without the use of PPA, the distribution loses valuable testing and > improvements. As a team, we do not have the resources to determine that > the reporter was not sent to the PPA file to test an improvement. The > PPA is not an authorized Ubuntu repository, however, no bug should be > invalid simply because it was reported against a PPA. I have seen > several developers on IRC and in launchpad request users test a package > in their PPA. If that package works, it may go on to be placed in the > distribution. The question of whether a bug report is a valid bug or not is completely separate from the question of whether it belongs in Ubuntu's bug tracker. We can debate how useful PPAs are all day long but that's not the real issue I don't think. > My opinion: > > Bugs against a PPA should not be invalid bugs. They should be clearly > identified as part of bug triage as being against a PPA, and the PPA > owner should have a chance to decide what to do with the bug. This > could be easily accomplished by adding a PPA tag to the bugs, and/or > add [PPA] to the summary. I think rather the bugs should *not* be filed in Ubuntu's bug tracker but sent to the PPA owner. They can forward the bug on to Ubuntu if they determine it to be an Ubuntu bug. What you're suggesting is similar to us filing all our bugs in Debian's BTS and just flagging them as "ubuntu". I don't think Debian would appreciate that too much as I don't think most Ubuntu maintainers would appreciate bugs in our bug tracker from 3rd party packages. It makes both triage and bug fixing just that much harder if we have to always worry about what somebody else has maybe done and track down changes in all the PPAs. > Perhaps a better procedure that tags would be to create a package for > the PPA. As bug reporters will not normally have the knowledge to > create that package, it will become the job of the triage team. That > involves more work for a team with enough work already. Launchpad doesn't have the ability to handle "ghost" packages. The best thing I can think of is to make Launchpad grow functionality to file bugs against PPAs. People should be filing bugs in the place where they got the software. -Jordan From hggdh2 at gmail.com Fri Mar 6 18:13:34 2009 From: hggdh2 at gmail.com (hggdh) Date: Fri, 6 Mar 2009 12:13:34 -0600 Subject: Bugs Reported Against a PPA In-Reply-To: <82926f0e0903060855u337cbe55m558e59be607a2d33@mail.gmail.com> References: <20090306062030.0b73f1f6@teamcharliesangels.com> <82926f0e0903060855u337cbe55m558e59be607a2d33@mail.gmail.com> Message-ID: <20090306121334.5711dc83@xango2> On Fri, 6 Mar 2009 08:55:41 -0800 Jordan Mantha wrote: > > My opinion: > > > > Bugs against a PPA should not be invalid bugs. They should be > > clearly identified as part of bug triage as being against a PPA, > > and the PPA owner should have a chance to decide what to do with > > the bug. This could be easily accomplished by adding a PPA tag to > > the bugs, and/or add [PPA] to the summary. > > I think rather the bugs should *not* be filed in Ubuntu's bug tracker > but sent to the PPA owner. I disagree. The easiest way to forward a bug to the PPA owner is by filling it as a bug... >They can forward the bug on to Ubuntu if > they determine it to be an Ubuntu bug. What you're suggesting is > similar to us filing all our bugs in Debian's BTS and just flagging > them as "ubuntu". I don't think Debian would appreciate that too much > as I don't think most Ubuntu maintainers would appreciate bugs in our > bug tracker from 3rd party packages. This example, or so it seems to me, is not quite applicable: 1. PPAs allows one to build *Ubuntu* packages (or derivatives); 2. PPAs allows for specific testing of new features or upstream bug fixes; 3. PPAs can also be abused, of course; nevertheless the point here is not curbing or controlling such abuse, but allowing for tracking of issues on packages that satisfy (2) above. > It makes both triage and bug > fixing just that much harder if we have to always worry about what > somebody else has maybe done and track down changes in all the PPAs. Nobody proposed that, if I understand the thread. What was proposed is that PPA bugs should be recorded on Malone, and in such a way that they would be clearly understood as *NOT* official Ubuntu bugs. > > Perhaps a better procedure that tags would be to create a package > > for the PPA. As bug reporters will not normally have the knowledge > > to create that package, it will become the job of the triage team. > > That involves more work for a team with enough work already. > > Launchpad doesn't have the ability to handle "ghost" packages. Indeed, and, for full support of PPAs, this should be addressed. > The best thing I can think of is to make Launchpad grow functionality > to file bugs against PPAs. People should be filing bugs in the place > where they got the software. I agree, and this is also what I proposed. But this functionality does not currently exist in Malone -- and this is also why I suggested involving Malone/LP development in this. But we should not need to wait... We can still abuse Malone, until such a day arrives that Malone/LP development catches up. The other option would be to forbid such abuse -- which would mean that workflow "bugs" should also be dropped (since they are also not bugs, after all, and we are abusing Malone on this). Cheers, ..hggdh.. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From pochu at ubuntu.com Fri Mar 6 18:43:00 2009 From: pochu at ubuntu.com (Emilio Pozuelo Monfort) Date: Fri, 06 Mar 2009 19:43:00 +0100 Subject: Bugs Reported Against a PPA In-Reply-To: <20090306121334.5711dc83@xango2> References: <20090306062030.0b73f1f6@teamcharliesangels.com> <82926f0e0903060855u337cbe55m558e59be607a2d33@mail.gmail.com> <20090306121334.5711dc83@xango2> Message-ID: <49B16EB4.50007@ubuntu.com> hggdh wrote: > On Fri, 6 Mar 2009 08:55:41 -0800 > Jordan Mantha wrote: > >>> My opinion: >>> >>> Bugs against a PPA should not be invalid bugs. They should be >>> clearly identified as part of bug triage as being against a PPA, >>> and the PPA owner should have a chance to decide what to do with >>> the bug. This could be easily accomplished by adding a PPA tag to >>> the bugs, and/or add [PPA] to the summary. >> I think rather the bugs should *not* be filed in Ubuntu's bug tracker >> but sent to the PPA owner. > > I disagree. The easiest way to forward a bug to the PPA owner is by > filling it as a bug... But not in Ubuntu. It's ok if a developer uses a PPA before uploading something to the archive and asks to report bugs in the bug tracker, but not as a general rule. The solution is not to allow people to submit bugs from outside the archive in the bug tracker, but to ask the Launchpad devs to provide a way to report bugs against a PPA. Cheers, Emilio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From laserjock at ubuntu.com Fri Mar 6 19:51:59 2009 From: laserjock at ubuntu.com (Jordan Mantha) Date: Fri, 6 Mar 2009 11:51:59 -0800 Subject: Bugs Reported Against a PPA In-Reply-To: <20090306121334.5711dc83@xango2> References: <20090306062030.0b73f1f6@teamcharliesangels.com> <82926f0e0903060855u337cbe55m558e59be607a2d33@mail.gmail.com> <20090306121334.5711dc83@xango2> Message-ID: <82926f0e0903061151v2991c563q65b995b25548fe48@mail.gmail.com> On Fri, Mar 6, 2009 at 10:13 AM, hggdh wrote: > On Fri, 6 Mar 2009 08:55:41 -0800 > Jordan Mantha wrote: > >> > My opinion: >> > >> > Bugs against a PPA should not be invalid bugs. They should be >> > clearly identified as part of bug triage as being against a PPA, >> > and the PPA owner should have a chance to decide what to do with >> > the bug. This could be easily accomplished by adding a PPA tag to >> > the bugs, and/or add [PPA] to the summary. >> >> I think rather the bugs should *not* be filed in Ubuntu's bug tracker >> but sent to the PPA owner. > > I disagree. The easiest way to forward a bug to the PPA owner is by > filling it as a bug... But not in Ubuntu. Filing the bug in Ubuntu forwards the bug to Ubuntu, not the PPA owner. >>They can forward the bug on to Ubuntu if >> they determine it to be an Ubuntu bug. What you're suggesting is >> similar to us filing all our bugs in Debian's BTS and just flagging >> them as "ubuntu". I don't think Debian would appreciate that too much >> as I don't think most Ubuntu maintainers would appreciate bugs in our >> bug tracker from 3rd party packages. > > This example, or so it seems to me, is not quite applicable: > > 1. PPAs allows one to build *Ubuntu* packages (or derivatives); > 2. PPAs allows for specific testing of new features or upstream bug > fixes; > 3. PPAs can also be abused, of course; nevertheless the point here is > not curbing or controlling such abuse, but allowing for tracking of > issues on packages that satisfy (2) above. PPA packages are *not* Ubuntu packages. PPAs can be used for any purpose and we don't need bugs from them. >> It makes both triage and bug >> fixing just that much harder if we have to always worry about what >> somebody else has maybe done and track down changes in all the PPAs. > > Nobody proposed that, if I understand the thread. What was proposed is > that PPA bugs should be recorded on Malone, and in such a way that they > would be clearly understood as *NOT* official Ubuntu bugs. The can be recorded in Malone but *should* not be in Ubuntu's bug tracker (i.e. launchpad.net/ubuntu/ ) >> > Perhaps a better procedure that tags would be to create a package >> > for the PPA. As bug reporters will not normally have the knowledge >> > to create that package, it will become the job of the triage team. >> > That involves more work for a team with enough work already. >> >> Launchpad doesn't have the ability to handle "ghost" packages. > > Indeed, and, for full support of PPAs, this should be addressed. > >> The best thing I can think of is to make Launchpad grow functionality >> to file bugs against PPAs. People should be filing bugs in the place >> where they got the software. > > I agree, and this is also what I proposed. But this functionality does > not currently exist in Malone -- and this is also why I suggested > involving Malone/LP development in this. But we should not need to > wait... Why not? > We can still abuse Malone, until such a day arrives that Malone/LP > development catches up. The other option would be to forbid such abuse > -- which would mean that workflow "bugs" should also be dropped (since > they are also not bugs, after all, and we are abusing Malone on this). Workflow bugs are different. Workflow bugs, while perhaps not strictly code bugs, *are* Ubuntu bugs. You're talking about allowing non-Ubuntu bugs into Ubuntu's bug tracker, which is an entirely different abuse. What about derivatives that use 3rd party repos, should we allow them too? Bottom line, if a package isn't in Ubuntu its bugs really shouldn't be in Ubuntu's bug tracker and should instead be sent to the person who made the package. -Jordan From andres.mujica at ubuntu.com Fri Mar 6 20:08:29 2009 From: andres.mujica at ubuntu.com (Andres Mujica) Date: Fri, 06 Mar 2009 15:08:29 -0500 Subject: Bugs Reported Against a PPA In-Reply-To: <20090306121334.5711dc83@xango2> References: <20090306062030.0b73f1f6@teamcharliesangels.com> <82926f0e0903060855u337cbe55m558e59be607a2d33@mail.gmail.com> <20090306121334.5711dc83@xango2> Message-ID: <1236370109.14843.51.camel@tecnica.seaq.intranet> > of PPAs, this should be addressed. > > > The best thing I can think of is to make Launchpad grow functionality > > to file bugs against PPAs. People should be filing bugs in the place > > where they got the software. > https://bugs.edge.launchpad.net/malone/+bug/179873 That would be the bug. > I agree, and this is also what I proposed. But this functionality does > not currently exist in Malone -- and this is also why I suggested > involving Malone/LP development in this. But we should not need to > wait... > Maybe in the meantime tag the bugs with [PPA] at the title and ppa at the tag? Regards, Andres Mujica -------------- next part -------------- An HTML attachment was scrubbed... URL: From andres.mujica at ubuntu.com Fri Mar 6 20:36:45 2009 From: andres.mujica at ubuntu.com (Andres Mujica) Date: Fri, 06 Mar 2009 15:36:45 -0500 Subject: Bugs Reported Against a PPA In-Reply-To: <20090306081447.695d74a4@xango2> References: <20090306062030.0b73f1f6@teamcharliesangels.com> <20090306081447.695d74a4@xango2> Message-ID: <1236371805.14843.52.camel@tecnica.seaq.intranet> > But I really think the Malone folks should be involved here. I am also > unaware of an easy way to search on packages provided by PPAs. https://edge.launchpad.net/ubuntu/+ppas http://ppa-search.appspot.com/ > Thank you for raising the issue, Charlie. > > Cheers, > > ..hggdh.. Andres Mujica -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at ubuntu.com Fri Mar 6 22:13:00 2009 From: brian at ubuntu.com (Brian Murray) Date: Fri, 6 Mar 2009 14:13:00 -0800 Subject: Bugs Reported Against a PPA In-Reply-To: <20090306062030.0b73f1f6@teamcharliesangels.com> References: <20090306062030.0b73f1f6@teamcharliesangels.com> Message-ID: <20090306221300.GR7788@murraytwins.com> On Fri, Mar 06, 2009 at 06:20:30AM -0700, Charlie Kravetz wrote: > It has been brought up that we currently have no policy in place for > bugs reported against a Personal Package Archive(PPA) in launchpad. > > The majority of bug reporters are attempting to help improve Ubuntu. > Without the use of PPA, the distribution loses valuable testing and > improvements. As a team, we do not have the resources to determine that > the reporter was not sent to the PPA file to test an improvement. The > PPA is not an authorized Ubuntu repository, however, no bug should be > invalid simply because it was reported against a PPA. I have seen > several developers on IRC and in launchpad request users test a package > in their PPA. If that package works, it may go on to be placed in the > distribution. Stepping back a bit I decided to make a guess at how many of these there actually are. I used the new-bug-description script[1], part of the ubuntu-qa tools, and looked for bugs containing either the string "~ppa" or "ppa.launchpad.net". I came up with about 30 bug reports for the month of February and 6 so far for March. Compared to the total volume of bugs[2] for those months this is a drop in the bucket. [1] https://code.edge.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master [2] http://www.murraytwins.com/blog/?p=38 -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From brian at ubuntu.com Fri Mar 6 22:16:03 2009 From: brian at ubuntu.com (Brian Murray) Date: Fri, 6 Mar 2009 14:16:03 -0800 Subject: Bugs Reported Against a PPA In-Reply-To: <1236371805.14843.52.camel@tecnica.seaq.intranet> References: <20090306062030.0b73f1f6@teamcharliesangels.com> <20090306081447.695d74a4@xango2> <1236371805.14843.52.camel@tecnica.seaq.intranet> Message-ID: <20090306221603.GS7788@murraytwins.com> On Fri, Mar 06, 2009 at 03:36:45PM -0500, Andres Mujica wrote: > > > > But I really think the Malone folks should be involved here. I am also > > unaware of an easy way to search on packages provided by PPAs. > > > > https://edge.launchpad.net/ubuntu/+ppas > http://ppa-search.appspot.com/ Briefly looking at both of these and the Launchpad API there doesn't seem to be a way to get from something like "kdebase-workspace-bin 4:4.2.0-0ubuntu1~intrepid1~ppa7"[1] to the owner of the PPA. This is really unfortunate as it doesn't provide us a way to contact the person who would be most interested in the bug report. [1] http://launchpad.net/bugs/330351 -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From a.starr.b at gmail.com Fri Mar 6 22:16:06 2009 From: a.starr.b at gmail.com (Andrew) Date: Fri, 6 Mar 2009 17:16:06 -0500 Subject: Bugs Reported Against a PPA In-Reply-To: <20090306062030.0b73f1f6@teamcharliesangels.com> References: <20090306062030.0b73f1f6@teamcharliesangels.com> Message-ID: On Fri, Mar 6, 2009 at 8:20 AM, Charlie Kravetz wrote: > It has been brought up that we currently have no policy in place for > bugs reported against a Personal Package Archive(PPA) in launchpad. Generally, the way I handle these situations is to open a blank upstream task (not actually linked to an upstream bug tracker) and subscribe the PPA owner if the bug is a packaging issue. If the PPA is owned by upstream or packaging a new upstream release not yet in Ubuntu and the bug is in the application not the packaging, then I open an upstream task and forward upstream. These shouldn't be reported against the Ubuntu packages as the bugs aren't actually in Ubuntu in most cases. Ideally, Launchpad should provide bug tracking for individual PPAs. - Andrew Starr-Bochicchio Ubuntu Contributing Developer From brian at ubuntu.com Fri Mar 6 22:22:02 2009 From: brian at ubuntu.com (Brian Murray) Date: Fri, 6 Mar 2009 14:22:02 -0800 Subject: Bugs Reported Against a PPA In-Reply-To: <1236370109.14843.51.camel@tecnica.seaq.intranet> References: <20090306062030.0b73f1f6@teamcharliesangels.com> <82926f0e0903060855u337cbe55m558e59be607a2d33@mail.gmail.com> <20090306121334.5711dc83@xango2> <1236370109.14843.51.camel@tecnica.seaq.intranet> Message-ID: <20090306222202.GT7788@murraytwins.com> On Fri, Mar 06, 2009 at 03:08:29PM -0500, Andres Mujica wrote: > > of PPAs, this should be addressed. > > > > > The best thing I can think of is to make Launchpad grow functionality > > > to file bugs against PPAs. People should be filing bugs in the place > > > where they got the software. > > > > > https://bugs.edge.launchpad.net/malone/+bug/179873 > > That would be the bug. > > > > I agree, and this is also what I proposed. But this functionality does > > not currently exist in Malone -- and this is also why I suggested > > involving Malone/LP development in this. But we should not need to > > wait... > > > > > > Maybe in the meantime tag the bugs with [PPA] at the title and ppa at the tag? I think setting the bug report to Invalid, since we have no way to find out who the owner of the PPA is nor a guarantee that they've subscribed to the package bug reports, and modifying the title and tagging as you've suggested is the best available option. This will still allow PPA owners to find bug reports if they wish to go looking for them. While this isn't the ideal solution I believe it is the least objectionable. When its easier to associate package versions with PPA owners, or the previously mentioned Malone bug is resolved or PPA bug report volume increases we should revisit the situation. -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From cjk at teamcharliesangels.com Fri Mar 6 19:55:49 2009 From: cjk at teamcharliesangels.com (Charlie Kravetz) Date: Fri, 6 Mar 2009 12:55:49 -0700 Subject: Bugs Reported Against a PPA In-Reply-To: <49B16EB4.50007@ubuntu.com> References: <20090306062030.0b73f1f6@teamcharliesangels.com> <82926f0e0903060855u337cbe55m558e59be607a2d33@mail.gmail.com> <20090306121334.5711dc83@xango2> <49B16EB4.50007@ubuntu.com> Message-ID: <20090306125549.53e6a78a@teamcharliesangels.com> On Fri, 06 Mar 2009 19:43:00 +0100 Emilio Pozuelo Monfort wrote: > hggdh wrote: > > On Fri, 6 Mar 2009 08:55:41 -0800 > > Jordan Mantha wrote: > > > >>> My opinion: > >>> > >>> Bugs against a PPA should not be invalid bugs. They should be > >>> clearly identified as part of bug triage as being against a PPA, > >>> and the PPA owner should have a chance to decide what to do with > >>> the bug. This could be easily accomplished by adding a PPA tag to > >>> the bugs, and/or add [PPA] to the summary. > >> I think rather the bugs should *not* be filed in Ubuntu's bug > >> tracker but sent to the PPA owner. > > > > I disagree. The easiest way to forward a bug to the PPA owner is by > > filling it as a bug... > > But not in Ubuntu. It's ok if a developer uses a PPA before uploading > something to the archive and asks to report bugs in the bug tracker, > but not as a general rule. > > The solution is not to allow people to submit bugs from outside the > archive in the bug tracker, but to ask the Launchpad devs to provide > a way to report bugs against a PPA. > > Cheers, > Emilio > While we are asking, what do you do with the bugs found? I find it hard to believe invalidating the bugs against a PPA is doing anyone any good. It may be fast, but we need a way to track the bugs until they can be reported against a PPA. I simply propose that the bugs are not simply marked invalid in the meantime. I am all for the idea of other solutions. But I also think we need an interim solution while working toward the permanent fix. -- Charlie Kravetz Linux Registered User Number 425914 [http://counter.li.org/] Never let anyone steal your DREAM. [http://keepingdreams.com] From brunogirin at gmail.com Sat Mar 7 10:34:38 2009 From: brunogirin at gmail.com (Bruno Girin) Date: Sat, 7 Mar 2009 10:34:38 +0000 Subject: Bugs Reported Against a PPA In-Reply-To: <20090306125549.53e6a78a@teamcharliesangels.com> References: <20090306062030.0b73f1f6@teamcharliesangels.com> <82926f0e0903060855u337cbe55m558e59be607a2d33@mail.gmail.com> <20090306121334.5711dc83@xango2> <49B16EB4.50007@ubuntu.com> <20090306125549.53e6a78a@teamcharliesangels.com> Message-ID: <6cad31400903070234r31debe86m41a720476fe8713b@mail.gmail.com> 2009/3/6 Charlie Kravetz : > On Fri, 06 Mar 2009 19:43:00 +0100 > Emilio Pozuelo Monfort wrote: > >> hggdh wrote: >> > On Fri, 6 Mar 2009 08:55:41 -0800 >> > Jordan Mantha wrote: >> > >> >>> My opinion: >> >>> >> >>> Bugs against a PPA should not be invalid bugs. They should be >> >>> clearly identified as part of bug triage as being against a PPA, >> >>> and the PPA owner should have a chance to decide what to do with >> >>> the bug. This could be easily accomplished by adding a PPA tag to >> >>> the bugs, and/or add [PPA] to the summary. >> >> I think rather the bugs should *not* be filed in Ubuntu's bug >> >> tracker but sent to the PPA owner. >> > >> > I disagree. The easiest way to forward a bug to the PPA owner is by >> > filling it as a bug... >> >> But not in Ubuntu. It's ok if a developer uses a PPA before uploading >> something to the archive and asks to report bugs in the bug tracker, >> but not as a general rule. >> >> The solution is not to allow people to submit bugs from outside the >> archive in the bug tracker, but to ask the Launchpad devs to provide >> a way to report bugs against a PPA. >> >> Cheers, >> Emilio >> > > While we are asking, what do you do with the bugs found? I find it > hard to believe invalidating the bugs against a PPA is doing anyone any > good. It may be fast, but we need a way to track the bugs until they > can be reported against a PPA. > > I simply propose that the bugs are not simply marked invalid in the > meantime. I am all for the idea of other solutions. But I also think we > need an interim solution while working toward the permanent fix. As a user who is just trying to do my bit to make Ubuntu better but who is not (yet) aware of the details, I have a stupid question: how do I know whether I should report a bug against a PPA or against Ubuntu? Should I report against a PPA if the bug is related to a piece of software I obtained by adding a third party software source? If that is the case, how do I know that the software concerned is not part of the Ubuntu sources? This is why I agree with Charlie: we need a way to deal with bugs against a PPA that have been reported in Ubuntu in a way that helps resolving those bugs. Users just want to know what is the best way to get their problem resolved so we should help them in that. We could do the following: - Educate the users by having a standard response to send back to the bug reporter explaining that the bug is a PPA bug, what is a PPA in the first place and what they should do to report it to the person who can actually resolve it. - Mark the bug as a PPA bug but not invalidate it: by doing this, we acknowledge the problem exist, even if we can't resolve it in Ubuntu itself, and if someone else wants to report the same problem they can find it and not report a duplicate. Then, in an ideal world, we should be able to forward the bug to the PPA and have nice tools to deal with it. But for now I think Charlie's proposal is a good one. My £0.02 (which the way the pound is going may be worth nothing these days) Bruno From martinmai1024 at web.de Mon Mar 9 20:41:25 2009 From: martinmai1024 at web.de (Martin Mai) Date: Mon, 09 Mar 2009 21:41:25 +0100 Subject: Announcing the Next Ubuntu Hug Day! - 12th of March, 2009 Message-ID: <1236631285.6144.2.camel@martin-laptop> Fellow Ubuntu Triagers! This week's HugDay target is *drum roll please* SAMBA! * 71 New bugs need a hug * 35 Incomplete bugs need a status check * 37 Confirmed bugs need a review Bookmark it, add it to your calendars, turn over those egg-timers! * 12th of March, 2009 * http://wiki.ubuntu.com/UbuntuBugDay/20090312 Can't stress it enough: everyone can help! Have some time? Triage boogz! I won't be upset if you get a headstart~ ;) Have a blog? Blog about Hugday! Have some screen space? Open #ubuntu-bugs and keep an eye out for newcomers in need. Have minions? Teach THEM to triage for you! :) Wanna be famous? Is easy! remember to use 5-A-day so if you do a good work your name could be listed at the top 5-A-Day Contributors in the Ubuntu Hall of Fame page! Make a difference; we will be in #ubuntu-bugs (FreeNode) all day and night, and will be ready to answer your questions about how to help. If you're new to all this, head to http://wiki.ubuntu.com/Bugs Have a nice day, Martin [From the BugSquad] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From martinmai1024 at web.de Mon Mar 16 17:55:01 2009 From: martinmai1024 at web.de (Martin Mai) Date: Mon, 16 Mar 2009 18:55:01 +0100 Subject: Announcing the Next Ubuntu Hug Day! - 19th of March, 2009 Message-ID: <1237226101.6134.7.camel@martin-laptop> Fellow Ubuntu Triagers! This week's HugDay target is *drum roll please* cups! * 85 New bugs need a hug * 27 Incomplete bugs need a status check * 11 Confirmed bugs need a review Bookmark it, add it to your calendars, turn over those egg-timers! * 19th of March, 2009 * http://wiki.ubuntu.com/UbuntuBugDay/20090319 Can't stress it enough: everyone can help! Have some time? Triage boogz! I won't be upset if you get a headstart~ ;) Have a blog? Blog about Hugday! Have some screen space? Open #ubuntu-bugs and keep an eye out for newcomers in need. Have minions? Teach THEM to triage for you! :) Wanna be famous? Is easy! remember to use 5-A-day so if you do a good work your name could be listed at the top 5-A-Day Contributors in the Ubuntu Hall of Fame page! Make a difference; we will be in #ubuntu-bugs (FreeNode) all day and night, and will be ready to answer your questions about how to help. If you're new to all this, head to http://wiki.ubuntu.com/Bugs Have a nice day, Martin [From the BugSquad] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From brian at ubuntu.com Mon Mar 16 21:36:04 2009 From: brian at ubuntu.com (Brian Murray) Date: Mon, 16 Mar 2009 14:36:04 -0700 Subject: Patch Testing Message-ID: <20090316213604.GC7786@murraytwins.com> The other week Brian Curtis mentioned an interest in learning how to test patches that are included in bug reports. I thought this would be some useful documentation to write and that it fit well in working with bugs with patches[1]. I've written the steps[2] that I perform to test patches and move them further along the fixing process. I've gone through the process of testing patches a couple of times following that documentation and it seems to work fairly well, but I'm biased! If you are interested in reducing the quantity of unfixed bugs with patches[3] or want to know how test patches - please use new wiki page[2] to help you through the process. I'm interested to hear what people think and how it can be improved. [1] https://wiki.ubuntu.com/Bugs/Patches [2] https://wiki.ubuntu.com/Bugs/PatchTesting [3] http://qa.ubuntu.com/reports/launchpad-database/unfixed-bugs-with-patches.html Thanks, -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From panbalag1 at gmail.com Fri Mar 20 16:22:28 2009 From: panbalag1 at gmail.com (Prasanth Anbalagan) Date: Fri, 20 Mar 2009 12:22:28 -0400 Subject: "Also notified" field in a bug report Message-ID: <7f75fcac0903200922v421635e4v22dce06b1f6738b9@mail.gmail.com> Hi all, Could someone point me where I could learn about the fields that appear in a bug report or about the anatomy of the a report. I could sort out most of the fields, but those like "Subscribers" , "Also notified" etc, I couldn't. Can someone help me on this. Regards Prasanth -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at ubuntu.com Fri Mar 20 16:30:59 2009 From: brian at ubuntu.com (Brian Murray) Date: Fri, 20 Mar 2009 09:30:59 -0700 Subject: "Also notified" field in a bug report In-Reply-To: <7f75fcac0903200922v421635e4v22dce06b1f6738b9@mail.gmail.com> References: <7f75fcac0903200922v421635e4v22dce06b1f6738b9@mail.gmail.com> Message-ID: <20090320163059.GP6229@murraytwins.com> On Fri, Mar 20, 2009 at 12:22:28PM -0400, Prasanth Anbalagan wrote: > Hi all, > > Could someone point me where I could learn about the fields that appear in a > bug report or about the anatomy of the a report. > > I could sort out most of the fields, but those like "Subscribers" , "Also > notified" etc, I couldn't. Can someone help me on this. Subscribers are divided into two distinct sections - direct and indirect. When you see the Subscribers label that is people directly subscribed to that particular bug report. The Also Notified section covers people subscribed to the package's bug reports or possibly the whole distributions bug report. There is also a From Duplicates section which is people who are subscribed to duplicate bug reports. -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From panbalag1 at gmail.com Mon Mar 23 15:28:45 2009 From: panbalag1 at gmail.com (Prasanth Anbalagan) Date: Mon, 23 Mar 2009 11:28:45 -0400 Subject: Anatomy of a bug report Message-ID: <7f75fcac0903230828we00148dmf715104853fb58bf@mail.gmail.com> Hi all, Could someone point me to the documentation where I can learn about the anatomy of a bug report ...For example, I'm interested in learning about the fields *When : 2007-04-11 Confirmed : 2007-11-19 Assigned : 2007-11-02 Started work : 2008-08-18 Completed : 2008-08-18* Regards Prasanth -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfger at gmail.com Mon Mar 23 15:36:50 2009 From: wolfger at gmail.com (Wolfger) Date: Mon, 23 Mar 2009 11:36:50 -0400 Subject: Anatomy of a bug report In-Reply-To: <7f75fcac0903230828we00148dmf715104853fb58bf@mail.gmail.com> References: <7f75fcac0903230828we00148dmf715104853fb58bf@mail.gmail.com> Message-ID: <3b00b3330903230836r66e821edib6462671e452b8b1@mail.gmail.com> I think you'll find everything you need from here: https://wiki.ubuntu.com/Bugs 2009/3/23 Prasanth Anbalagan > > > > > > > > > > > Hi all, > > Could someone point me to the documentation where I can learn about the > anatomy of a bug report ...For example, I'm interested in learning about the > fields > > *When : 2007-04-11 > Confirmed : 2007-11-19 > Assigned : 2007-11-02 > Started work : 2008-08-18 > Completed : 2008-08-18* > > Regards > Prasanth > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -- Wolfger http://wolfger.wordpress.com/ http://twitter.com/wolfger http://identi.ca/wolfger The world is a mess, and I just... need to rule it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at ubuntu.com Wed Mar 25 15:16:59 2009 From: brian at ubuntu.com (Brian Murray) Date: Wed, 25 Mar 2009 08:16:59 -0700 Subject: Anatomy of a bug report In-Reply-To: <7f75fcac0903230828we00148dmf715104853fb58bf@mail.gmail.com> References: <7f75fcac0903230828we00148dmf715104853fb58bf@mail.gmail.com> Message-ID: <20090325151658.GA6229@murraytwins.com> On Mon, Mar 23, 2009 at 11:28:45AM -0400, Prasanth Anbalagan wrote: > Hi all, > > Could someone point me to the documentation where I can learn about the > anatomy of a bug report ...For example, I'm interested in learning about the > fields > > *When : 2007-04-11 This is the date the bug task was opened, it can be different than the date the bug was reported since a bug report can have multiple bug tasks. > Confirmed : 2007-11-19 This is the date the bug task transitioned to the Confirmed status. > Assigned : 2007-11-02 This is the date that the bug task was assigned to someone. > Started work : 2008-08-18 The date the bug task's status transitioned to In Progress. > Completed : 2008-08-18* I'm not positive but this is probably the date the bug task transitioned to Fix Released. If you were to provide the bug number of the particular bug report you are looking at we could confirm this. Thanks, -- Brian Murray @ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From pedro at ubuntu.com Mon Mar 30 19:54:25 2009 From: pedro at ubuntu.com (Pedro Villavicencio Garrido) Date: Mon, 30 Mar 2009 15:54:25 -0400 Subject: Announcing the Next Ubuntu Hug Day! - April 02 2009 Message-ID: <1238442865.6824.9.camel@thylacine> Fellow Ubuntu Triagers! This week's HugDay target is *drum roll please* xorg-server and xserver-xorg-video-intel! * 49 New bugs need a hug. * 103 Incomplete bugs need a status check. * 81 Confirmed bugs need a review. * 16 Bugs with patches that need to be reviewed. Bookmark it, add it to your calendars, turn over those egg-timers! * April 02 2009 * https://wiki.ubuntu.com/UbuntuBugDay/20090402 Can't stress it enough: everyone can help! Have some time? Triage boogz! I won't be upset if you get a headstart~ ;) Have a blog? Blog about Hugday! Have some screen space? Open #ubuntu-bugs and keep an eye out for newcomers in need. Have minions? Teach THEM to triage for you! :) Wanna be famous? Is easy! remember to use 5-A-day so if you do a good work your name could be listed at the top 5-A-Day Contributors in the Ubuntu Hall of Fame page! Make a difference; we will be in #ubuntu-bugs (FreeNode) all day and night, and will be ready to answer your questions about how to help. If you're new to all this, head to http://wiki.ubuntu.com/Bugs Have a nice day, pedro.