From sense at qense.nl Fri May 2 18:20:14 2008 From: sense at qense.nl (Sense Hofstede) Date: Fri, 02 May 2008 20:20:14 +0200 Subject: Wiki packages pages Message-ID: <481B5B5E.9020307@qense.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A while ago I've started a bit with a 'project' to create wiki pages where you can find what information should be included in bug reports that you want to pass on to the developers/upstream. You can find that at http://wiki.ubuntu.com/Bugs/Triaging . But unfortunately it didn't became a success. That was because I forgot it and didn't have much time to spend on this. It also covers the same subject as http://wiki.ubuntu.com/DebuggingProcedures . I've talked with bdmurray about this. We thought that it would be the best to merge all documentation about different packages in one page for every source package as listed on Launchpad. These pages would be located at http://wiki.ubuntu.com/wiki/Bugs/Packages/{source_package_name} At this page you can find the tags that apply to this package, what files you should include with bug reports, other information you should include. Where you can find the upstream bug tracker, the Ubuntu maintainers for that package and links to important pages and websites about this package. I want to ask you for your thoughts on this. Do you think it's necessary? Do you want to help or have you got a great idea? Please mail to this maillist. Sense Hofstede -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIG1ryxft9JZoh5JwRAlRlAKC+lrdnjEx2uWMGafG4rg51z/Eb/QCfQMQb Cw1kT4P8opVSilpPMClmt8o= =J+/r -----END PGP SIGNATURE----- From sense at qense.nl Sun May 4 13:57:07 2008 From: sense at qense.nl (Sense Hofstede) Date: Sun, 04 May 2008 15:57:07 +0200 Subject: Apport Bugs Message-ID: <481DC0B3.5010000@qense.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've got the feeling that bug reports reported by apport from .crash files are very often 'forgotten'. I think this is because of the private flag and an awful lot of information which could frighten the triager. But that's an enormous waste, since those reports are very complete and still are bugs. What I suggest is that a special section will be created in the guide which explains when an apport report is complete and what to do with them(and the private flag). Because I also often am not sure what to do with the reports. Any thoughts on this? Do you experience the same? - -- Sense Hofstede -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIHcCyxft9JZoh5JwRAgPHAJ9XdI0Iy75mklgrfKFu4tgAu1UBNgCgoYWF aiI1ImMDWRDqKvWV+BC2l1Y= =Go/o -----END PGP SIGNATURE----- From wolfger at gmail.com Sun May 4 17:08:00 2008 From: wolfger at gmail.com (Wolfger) Date: Sun, 4 May 2008 13:08:00 -0400 Subject: Incomplete with no response >30 days Message-ID: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> One of the things I like to do to whittle away at the mountain of open bugs is to take the least-recently-touched incomplete bugs and close them out with the canned response. The wiki indicates any bug incomplete for more than 4 weeks can be closed, and most of these are untouched for 4, 5, or 6 months. Sometimes more. One such recent bug: https://bugs.launchpad.net/ubuntu/+source/secvpn/+bug/154730 was reopened with a comment, "Dear bugsquad people: Please don't mess with archive management bugs. Ask bdmurray about it if you have questions." Now I can understand why this person would want to keep this bug open, but I don't think "incomplete" is an appropriate status ("in progress", maybe?), and the person working on this bug (for 6 months now?) should probably assign it to himself if he's actually working on it. Opinions? Comments? -- Wolfger http://wolfger.wordpress.com/ AOL IM: wolf4coyot Yahoo!Messenger: wolfgersilberbaer -------------- next part -------------- An HTML attachment was scrubbed... URL: From sense at qense.nl Sun May 4 17:15:22 2008 From: sense at qense.nl (Sense Hofstede) Date: Sun, 04 May 2008 19:15:22 +0200 Subject: Incomplete with no response >30 days In-Reply-To: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> Message-ID: <481DEF2A.8060705@qense.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wolfger schreef: > One of the things I like to do to whittle away at the mountain of open > bugs is to take the least-recently-touched incomplete bugs and close > them out with the canned response. The wiki indicates any bug incomplete > for more than 4 weeks can be closed, and most of these are untouched for > 4, 5, or 6 months. Sometimes more. > > One such recent bug: > https://bugs.launchpad.net/ubuntu/+source/secvpn/+bug/154730 > was reopened with a comment, "Dear bugsquad people: Please don't mess > with archive management bugs. Ask bdmurray about it if you have questions." > > Now I can understand why this person would want to keep this bug open, > but I don't think "incomplete" is an appropriate status ("in progress", > maybe?), and the person working on this bug (for 6 months now?) should > probably assign it to himself if he's actually working on it. > > Opinions? Comments? > > -- > Wolfger > http://wolfger.wordpress.com/ > AOL IM: wolf4coyot > Yahoo!Messenger: wolfgersilberbaer > I'd ask him to change the status, Incomlete isn't a good status I think. :) But half a year is a long time. It's a complete (pre-)release cycle! - -- Sense Hofstede -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIHe6+xft9JZoh5JwRAh6OAKCSkGktUrdWDHkIdQ704aLByWERpwCfTNF/ 3hWp2ygG7GXzcV0+/AYZQq4= =arhK -----END PGP SIGNATURE----- From ryanprior at gmail.com Sun May 4 17:25:02 2008 From: ryanprior at gmail.com (Ryan Prior) Date: Sun, 4 May 2008 12:25:02 -0500 Subject: Incomplete with no response >30 days In-Reply-To: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> Message-ID: <1172c9070805041025r57023fe6m403801caae7ff7b5@mail.gmail.com> I went ahead and assigned it to Mr. Kitterman, marking it "In Progress". If somebody disagrees with that assignment, please change it again. :-) -Ryan On Sun, May 4, 2008 at 12:08 PM, Wolfger wrote: > One of the things I like to do to whittle away at the mountain of open > bugs is to take the least-recently-touched incomplete bugs and close them > out with the canned response. The wiki indicates any bug incomplete for more > than 4 weeks can be closed, and most of these are untouched for 4, 5, or 6 > months. Sometimes more. > > One such recent bug: > https://bugs.launchpad.net/ubuntu/+source/secvpn/+bug/154730 > was reopened with a comment, "Dear bugsquad people: Please don't mess with > archive management bugs. Ask bdmurray about it if you have questions." > > Now I can understand why this person would want to keep this bug open, but > I don't think "incomplete" is an appropriate status ("in progress", maybe?), > and the person working on this bug (for 6 months now?) should probably > assign it to himself if he's actually working on it. > > Opinions? Comments? > > -- > Wolfger > http://wolfger.wordpress.com/ > AOL IM: wolf4coyot > Yahoo!Messenger: wolfgersilberbaer > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirrus at kirrus.co.uk Sun May 4 17:39:33 2008 From: kirrus at kirrus.co.uk (Johnathon Tinsley) Date: Sun, 4 May 2008 18:39:33 +0100 (BST) Subject: Incomplete with no response >30 days In-Reply-To: <481DEF2A.8060705@qense.nl> Message-ID: <8411977.26691209922773067.JavaMail.root@zimbra> ----- "Sense Hofstede" wrote: > I'd ask him to change the status, Incomlete isn't a good status I > think. > :) But half a year is a long time. It's a complete (pre-)release > cycle! > In that status, with that amount of time, closing it was the correct thing to do. If its assigned to someone and incomplete, I'll tend to post on the bug, asking if there is anything happening. If its not, then I'll just close it. The right thing to do here is to mark it in progress, confirmed or triaged, and assign it to the person thats working on it. Also, might be worth a mention, the replying comment was quite curt, and teeters just before the edge of when I'd send a CoC reminder. Most of us are just volunteers :) Kind Regards, Johnathon p.s. Sorry Sense, I sent this reply to your address directly instead of to the bugsquad - thats why you've got two copies. From hobbsee at ubuntu.com Mon May 5 08:09:11 2008 From: hobbsee at ubuntu.com (Sarah Hobbs) Date: Mon, 05 May 2008 18:09:11 +1000 Subject: Incomplete with no response >30 days In-Reply-To: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> Message-ID: <481EC0A7.2000104@ubuntu.com> Hey there! I second what ScottK has said here: for anything with ubuntu-release, ubuntu-archive, ubuntu-{universe,main}-sponsors, or motu-release subscribed, please leave those bugs alone. They're not filed by users only, and developers have almost always looked at the bugs, if not filed them themselves. They have a special sequence of steps to be followed, and the bug squad interfering with them is not helpful. The same occurs for sync and merge requests - just leave them alone, unless you're a developer with upload rights to Ubuntu (whether main or universe). The bug squad's aim is to make users bugs better, before a developer looks at them (last i knew) - it is *not* to fiddle with developer bugs. If you're unsure if the person is a developer, check the teams that they're in (ubuntu-dev means they have upload rights to at least part of Ubuntu) It would be helpful if you added this to your documentation. 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 kirrus at kirrus.co.uk Mon May 5 08:24:59 2008 From: kirrus at kirrus.co.uk (Johnathon Tinsley) Date: Mon, 5 May 2008 09:24:59 +0100 (BST) Subject: Incomplete with no response >30 days In-Reply-To: <481EC0A7.2000104@ubuntu.com> Message-ID: <4196803.26751209975899539.JavaMail.root@zimbra> ----- "Sarah Hobbs" wrote: > Hey there! > > I second what ScottK has said here: for anything with ubuntu-release, > > ubuntu-archive, ubuntu-{universe,main}-sponsors, or motu-release > subscribed, please leave those bugs alone. > > They're not filed by users only, and developers have almost always > looked at the bugs, if not filed them themselves. They have a special > sequence of steps to be followed, and the bug squad interfering with > them is not helpful. If you really want triagers to leave your bugs alone, you need to have a tag, or something. I can't see from that bug that it is anything to do with devs, its _not obvious_. The bug state was Incomplete, with no assignee, which means to us that its still in a triage state. > > > > The bug squad's aim is to make users bugs better, before a developer > looks at them (last i knew) - it is *not* to fiddle with developer > bugs. > If you're unsure if the person is a developer, check the teams that > they're in (ubuntu-dev means they have upload rights to at least part > of Ubuntu) I'm not going to look at the profile page of every reporter whose bug I triage to check if they're a dev, that would be a waste of time; more often than not they're an almost blank page, with just the reporters email address there. I've seen and will ignore Sync & Merge bugs, but only because I was told off for touching one before (should probably be documented somewhere). Again, it is NOT obvious from the bug report that that bug was a developer bug. You should tag it or change its status OUT of incomplete or new. As a rule, an "incomplete" or "new" bug is triager territory. Confirmed, In Progress and Triaged are all devs territory. Yes, our purpose is to gather information for devs, but how can we quickly see if a dev is working on a bug if its not in a working status, or assigned to a team or person, or tagged? > > > Kind Regards, Johnathon -- Blog: http://kirrus.co.uk From sense at qense.nl Mon May 5 08:56:00 2008 From: sense at qense.nl (Sense Hofstede) Date: Mon, 05 May 2008 10:56:00 +0200 Subject: Incomplete with no response >30 days In-Reply-To: <4196803.26751209975899539.JavaMail.root@zimbra> References: <4196803.26751209975899539.JavaMail.root@zimbra> Message-ID: <481ECBA0.5060704@qense.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johnathon Tinsley schreef: > ----- "Sarah Hobbs" wrote: > >> Hey there! >> >> I second what ScottK has said here: for anything with ubuntu-release, >> >> ubuntu-archive, ubuntu-{universe,main}-sponsors, or motu-release >> subscribed, please leave those bugs alone. >> >> They're not filed by users only, and developers have almost always >> looked at the bugs, if not filed them themselves. They have a special >> sequence of steps to be followed, and the bug squad interfering with >> them is not helpful. > > If you really want triagers to leave your bugs alone, you need to have a tag, or something. I can't see from that bug that it is anything to do with devs, its _not obvious_. The bug state was Incomplete, with no assignee, which means to us that its still in a triage state. > >> >> >> The bug squad's aim is to make users bugs better, before a developer >> looks at them (last i knew) - it is *not* to fiddle with developer >> bugs. >> If you're unsure if the person is a developer, check the teams that >> they're in (ubuntu-dev means they have upload rights to at least part >> of Ubuntu) > > I'm not going to look at the profile page of every reporter whose bug I triage to check if they're a dev, that would be a waste of time; more often than not they're an almost blank page, with just the reporters email address there. > > I've seen and will ignore Sync & Merge bugs, but only because I was told off for touching one before (should probably be documented somewhere). > > Again, it is NOT obvious from the bug report that that bug was a developer bug. You should tag it or change its status OUT of incomplete or new. As a rule, an "incomplete" or "new" bug is triager territory. Confirmed, In Progress and Triaged are all devs territory. > > Yes, our purpose is to gather information for devs, but how can we quickly see if a dev is working on a bug if its not in a working status, or assigned to a team or person, or tagged? > >> >> > > > Kind Regards, > > Johnathon > > I second the reply of Johnathon. It's sometimes very hard to determine if a bug is a 'developer bug'. And if we're going to leave all bugs reported by developers alone, you'll have to triage real bugs reported by you on your own. I think it would be better if you'd choose another status or use at least a tag. The sequence of steps is a bit weird if it includes bugs to be set on Incomplete instead of In Progress when someone's working on it, or has it at his/her ToDo list. Choosing another status would really help us, because they won't show up in our search results, and those are already huge. - -- Sense Hofstede -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIHsufxft9JZoh5JwRArZLAJ0c1YjWWp10lgUHCnP766MHqi4jNQCdEm9D UBja+EH72Q10wSfgAwqWBEs= =kYFD -----END PGP SIGNATURE----- From brian at ubuntu.com Mon May 5 20:13:27 2008 From: brian at ubuntu.com (Brian Murray) Date: Mon, 5 May 2008 13:13:27 -0700 Subject: Hug Day - 06 May 2008 Message-ID: <20080505201327.GW8395@murraytwins.com> We've been promoting the use of an application's "Help -> Report a Problem" menu item to bug reporters as a better way to report bugs as a lot of information is gathered automatically. These bug reports are identifiable by their 'apport-bug' tag and "ProblemType: Bug" in the description. I went looking for applications with large numbers of apport-bug tagged bugs and firefox-3.0 and firefox came out on top so I thought we'd look at those for the next Hug Day. You can find the list of bugs at: https://wiki.ubuntu.com/UbuntuBugDay/20080506 Some of these bug reports may not be actually about Firefox and will need to be assigned to a different package. Those that are really Firefox bug reports should be triaged following the debugging procedures: https://wiki.ubuntu.com/DebuggingFirefox . 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 pedro at ubuntu.com Tue May 6 20:44:56 2008 From: pedro at ubuntu.com (Pedro Villavicencio Garrido) Date: Tue, 06 May 2008 16:44:56 -0400 Subject: Celebrating Hug Day! - 08 May 2008 Message-ID: <1210106696.9309.49.camel@thylacine> Hello Ubuntu Lovers, On Thursday 08 of May we'll be celebrating a NetworkManager Hug Day: https://wiki.ubuntu.com/UbuntuBugDay/20080508 Our goal is to deal with all of the bugs on that list. 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, 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 08 of May 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 brian at ubuntu.com Tue May 6 23:55:15 2008 From: brian at ubuntu.com (Brian Murray) Date: Tue, 6 May 2008 16:55:15 -0700 Subject: Workflow Reports Message-ID: <20080506235515.GA12948@murraytwins.com> There have been some recent discussions about what I'll call workflow reports. These are not really bug reports but Launchpad's bug tracking system provides a convenient way to document, communicate and collaborate on these work flows. While these reports are the minority I thought it would be useful if there was an easier way to identify them. Subsequently, I've written a greasemonkey script that will add "This is a workflow report" to a bug's title for bugs with specific teams subscribed and hopefully we can avoid 'fiddling with developer bugs'. The greasemonkey script is available at http://people.ubuntu.com/~brian/greasemonkey/lp_workflowreports.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 mathiaz at ubuntu.com Wed May 7 01:05:16 2008 From: mathiaz at ubuntu.com (Mathias Gug) Date: Tue, 6 May 2008 21:05:16 -0400 Subject: Workflow Reports In-Reply-To: <20080506235515.GA12948@murraytwins.com> References: <20080506235515.GA12948@murraytwins.com> Message-ID: <20080507010515.GB6980@mathiaz.mathiaz.net> On Tue, May 06, 2008 at 04:55:15PM -0700, Brian Murray wrote: > There have been some recent discussions about what I'll call workflow > reports. These are not really bug reports but Launchpad's bug tracking > system provides a convenient way to document, communicate and > collaborate on these work flows. Do you have a specific bug number to show what you call a "workflow report" ? -- Mathias Gug Ubuntu Developer http://www.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 greg.grossmeier at gmail.com Wed May 7 01:22:33 2008 From: greg.grossmeier at gmail.com (Greg Grossmeier) Date: Tue, 06 May 2008 21:22:33 -0400 Subject: Workflow Reports In-Reply-To: <20080507010515.GB6980@mathiaz.mathiaz.net> References: <20080506235515.GA12948@murraytwins.com> <20080507010515.GB6980@mathiaz.mathiaz.net> Message-ID: <48210459.7000202@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - From the email that spurred this discussion: https://bugs.launchpad.net/ubuntu/+source/secvpn/+bug/154730 Best, Greg Mathias Gug wrote: > On Tue, May 06, 2008 at 04:55:15PM -0700, Brian Murray wrote: >> There have been some recent discussions about what I'll call workflow >> reports. These are not really bug reports but Launchpad's bug tracking >> system provides a convenient way to document, communicate and >> collaborate on these work flows. > > Do you have a specific bug number to show what you call a "workflow > report" ? > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSCEEWH0TRE10HeqfAQLZdQ/+Mg08YSEbiP0WI20WACH5CCFKB1773U7B xGxuYLLCiZBuiOjiZcxQL8nWflMRj7VqWq7fQ5ZfnAtds+FGbcN8f7JlwTLlx4M+ bJ70rSGfenxtk+/1A6LOUkpuqKaXzdg2JH4l6O+FCsaZDoOeSuWoJo+GAPxBVHiF oBLmQ1pAP0FmSBjmWuTx7zEEXK/eY+aw61fY9atiTt1aDpJ86thxj7cmGDnfQCX6 m2XW0VL+eG9Y7qBYQGGrbGPBT88KJ1/tKXrwuTIVdEmwISmXxeA3idYUkBwXB8Ex jgGPNwQX3vkysloVSgRNuWjJ9bAnEPXO+sgQD4xR8zJABaB4vFfs96nkG9IkCQiG Oozg7t3KJrZkhFELkub8AZD08aF6F9jXn3Z2lmjuBpPQdNrEzzq5OklRtWMz1ZdF OuzEetTWrmEV73sQ9xP8jZ4t7V6I0kWlPIv1eVl1WfHZ4Hcy1fIICFzPllxXp+Kp q1Wh3orZ7VyactToVQ68RUPmyzU3IX7E5bmuPvFN4YErj+SEvou6x6cnMK6JJJIB Y8KeJzSIrgCtSy97xYxY3m2Wjb1AYbOvM3+nSK+0+9V0tjVlrezIfZtxKBZ52ito Ye3Ot3W4crS/t2VHZqWcOEFeI04fXZ761dJSAYpNcnkPlA1Bb32LvBSUhkoxIkVa 8ZVQvjydT4k= =H0fO -----END PGP SIGNATURE----- From henrik at canonical.com Wed May 7 12:23:24 2008 From: henrik at canonical.com (Henrik Nilsen Omma) Date: Wed, 07 May 2008 13:23:24 +0100 Subject: Incomplete with no response >30 days In-Reply-To: <481EC0A7.2000104@ubuntu.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> Message-ID: <48219F3C.8090508@canonical.com> Sarah Hobbs wrote: > Hey there! > > I second what ScottK has said here: for anything with ubuntu-release, > ubuntu-archive, ubuntu-{universe,main}-sponsors, or motu-release > subscribed, please leave those bugs alone. > > They're not filed by users only, and developers have almost always > looked at the bugs, if not filed them themselves. They have a special > sequence of steps to be followed, and the bug squad interfering with > them is not helpful. I don't think that is a reasonable position. A small group is using the bug tracker in an unorthodox way to track issues that are not really bugs (let's call them tickets). That may be fine as we have no other mechanism to track these tasks ATM, but it does mean that the group who is using the tracker in this way needs to be flexible and adjust their approach to coexist more smoothly with other users of the system. It's not reasonable to expect new bug triagers to simply know these things. We can document it but that's not ideal because there is already a great deal to read when you are starting out. It's simply not right in my view that a new triager risks being flamed on the bug tracker for not having read that particular paragraph. If these bugs were all marked as In Progress then they would generally stay off the radar of the bugsquad and we would not have this confusion. The developers can then use tags, assignments or whatever to keep track of the state of each ticket. Alternatively, they could perhaps be filed against a separate Launchpad project set up for this purpose. We want to attract new volunteers to the bug triage community and adding extra complications and special cases to the bug workflow isn't helping. And being flamed on the bug tracker certainly doesn't help :) > > The bug squad's aim is to make users bugs better, before a developer > looks at them (last i knew) - it is *not* to fiddle with developer > bugs. If you're unsure if the person is a developer, check the teams > that they're in (ubuntu-dev means they have upload rights to at least > part of Ubuntu) Again, this is an unreasonable request. It adds a needles layer of complexity for a relatively small number of tickets and bugs. The developer community cannot expect the bugsquad to grow and flourish and provide much needed support to the development effort without being willing to help make the process simpler and be flexible on issues like this. Henrik Omma Ubuntu QA Manager From daniel.holbach at ubuntu.com Wed May 7 12:31:35 2008 From: daniel.holbach at ubuntu.com (Daniel Holbach) Date: Wed, 07 May 2008 14:31:35 +0200 Subject: Workflow Reports In-Reply-To: <20080506235515.GA12948@murraytwins.com> References: <20080506235515.GA12948@murraytwins.com> Message-ID: <4821A127.3070606@ubuntu.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Murray schrieb: > The greasemonkey script is available at > http://people.ubuntu.com/~brian/greasemonkey/lp_workflowreports.user.js Thanks a lot for dealing with the issue in a very pragmatic and straight-forward way. Do we currently link to these scripts in the wiki docs somewhere? Would it make sense to package them up and have them installable via a package? (ubuntu-qa-tools anybody?) Have a nice day, Daniel - -- My 5 today: #225740 (wml), #227261 (phpmyadmin), #192517 (memtest86+), #226999 (ubuntu), #227500 (libaudio-flac-header-perl) 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 iD8DBQFIIaEnRjrlnQWd1esRApcbAJ9BVDZsZWLEWpvZ+1cgI5PJejXcmACfW7BL YNWqVFBnY3/eJdT0KGKbN/A= =GWul -----END PGP SIGNATURE----- From wolfger at gmail.com Wed May 7 12:36:22 2008 From: wolfger at gmail.com (Wolfger) Date: Wed, 7 May 2008 08:36:22 -0400 Subject: Incomplete with no response >30 days In-Reply-To: <48219F3C.8090508@canonical.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> Message-ID: <3b00b3330805070536nde2b7ffuedcc4a2dce552513@mail.gmail.com> On Wed, May 7, 2008 at 8:23 AM, Henrik Nilsen Omma wrote: > I don't think that is a reasonable position. A small group is using the > bug tracker in an unorthodox way to track issues that are not really > bugs (let's call them tickets). That may be fine as we have no other > mechanism to track these tasks ATM, but it does mean that the group who > is using the tracker in this way needs to be flexible and adjust their > approach to coexist more smoothly with other users of the system. Thanks, Henrik. You've summed up my feelings word-for-word (though I didn't quote it all). Brian Murray responded to this issue earlier today with a Greasemonkey script that will help triagers avoid these bugs. That's a decent quick patch, but: 1) It forces triagers to use Firefox 2) It forces triagers to use Greasemonkey 3) Triagers have to know about the script's existence. It's an inherently flawed solution that misses the fact that some devs are using "incomplete" status in contradiction of the Ubuntu wiki definition. We could change the definition, I suppose, but that would make the status less useful in my opinion. -- Wolfger http://wolfger.wordpress.com/ AOL IM: wolf4coyot Yahoo!Messenger: wolfgersilberbaer From daniel.holbach at ubuntu.com Wed May 7 12:44:49 2008 From: daniel.holbach at ubuntu.com (Daniel Holbach) Date: Wed, 07 May 2008 14:44:49 +0200 Subject: Incomplete with no response >30 days In-Reply-To: <3b00b3330805070536nde2b7ffuedcc4a2dce552513@mail.gmail.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <3b00b3330805070536nde2b7ffuedcc4a2dce552513@mail.gmail.com> Message-ID: <4821A441.2040505@ubuntu.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wolfger schrieb: > On Wed, May 7, 2008 at 8:23 AM, Henrik Nilsen Omma wrote: > 1) It forces triagers to use Firefox Just for completeness' sake: it works with epiphany-browser (and epiphany-extensions) too. > 3) Triagers have to know about the script's existence. In my reply to Brian's announce I added my thoughts about it too. It'd be nice to have a ubuntu-qa-tools package, that'd depends on bughelper and shipped all kinds of useful stuff (like greasemonkey scripts). What do you think? > It's an inherently flawed solution that misses the fact that some devs > are using "incomplete" status in contradiction of the Ubuntu wiki > definition. We could change the definition, I suppose, but that would > make the status less useful in my opinion. The answer I gave above does not solve the problem you mention and I guess there will always be different contexts in which a bug status (or a subscription/assignment, etc) will be interpreted differently. We still should aim for bigger coherence though. Would it make sense to discuss this at UDS? Who'd be interested in leading such a session? Have a nice day, Daniel - -- My 5 today: #225740 (wml), #227261 (phpmyadmin), #192517 (memtest86+), #226999 (ubuntu), #227500 (libaudio-flac-header-perl) 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 iD8DBQFIIaRARjrlnQWd1esRAqq9AJ9eVem+YRQ/UbDZ0m7n9yGumeMJ2ACfdVlO Xm9a532/CeKh6aBkE20s2QI= =/wOO -----END PGP SIGNATURE----- From henrik at canonical.com Wed May 7 12:58:41 2008 From: henrik at canonical.com (Henrik Nilsen Omma) Date: Wed, 07 May 2008 13:58:41 +0100 Subject: Incomplete with no response >30 days In-Reply-To: <4821A441.2040505@ubuntu.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <3b00b3330805070536nde2b7ffuedcc4a2dce552513@mail.gmail.com> <4821A441.2040505@ubuntu.com> Message-ID: <4821A781.3040903@canonical.com> Daniel Holbach wrote: > >> 3) Trisetagers have to know about the script's existence. >> > > In my reply to Brian's announce I added my thoughts about it too. It'd > be nice to have a ubuntu-qa-tools package, that'd depends on bughelper > and shipped all kinds of useful stuff (like greasemonkey scripts). > That would be great! Having triage tools packaged all neatly together would make the work more productive and with everyone standardising on the same tools makes it easier to learn from each other. However I don't want these tools to be a pre-requisite for starting out with triage. In theory you could hit an archive admin ticket in your first ever round of triage and we don't want to make the likelihood and risk of making a mistake artificially high by introducing land mines that you need special tools to avoid :) > We still should aim for bigger coherence though. Would it make sense to > discuss this at UDS? Who'd be interested in leading such a session? Agreed. I can do that. I'll schedule it as a QA track session now. Henrik From hobbsee at ubuntu.com Thu May 8 14:03:15 2008 From: hobbsee at ubuntu.com (Sarah Hobbs) Date: Fri, 09 May 2008 00:03:15 +1000 Subject: Incomplete with no response >30 days In-Reply-To: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> Message-ID: <48230823.2050104@ubuntu.com> The documentation is now updated. See https://wiki.ubuntu.com/Bugs/HowToTriage#head-89f23324471028da4ff2dc496f0bdd299d72c093 Is that unclear? Any questions, thoughts or comments? Have I missed out any groups? 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 wolfger at gmail.com Thu May 8 14:43:30 2008 From: wolfger at gmail.com (Wolfger) Date: Thu, 8 May 2008 10:43:30 -0400 Subject: Incomplete with no response >30 days In-Reply-To: <48230823.2050104@ubuntu.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <48230823.2050104@ubuntu.com> Message-ID: <3b00b3330805080743v7b7be05dq6ea1942bc032fa94@mail.gmail.com> On Thu, May 8, 2008 at 10:03 AM, Sarah Hobbs wrote: > The documentation is now updated. See > https://wiki.ubuntu.com/Bugs/HowToTriage#head-89f23324471028da4ff2dc496f0bdd299d72c093 > > Is that unclear? Any questions, thoughts or comments? It's clear, but I'm also not satisfied with this as a solution. By applying this patch to our documentation, there will come a day when the search I use to find bugs which are stale will be populated for the first several pages by workflow "bugs". The previously suggested change to their procedure (use "in progress" status and/or assign the bug to somebody) enables us to easily avoid having these turn up in our searches. Or if somebody simply tells me I can change these to "in progress" when I see them as old and incomplete, they won't need to change their procedure at all. I'm willing to do the work. I just want a solution that doesn't impede my ability to do useful things. And as an aside, I used Bdmurray's greasemonkey script last night. I like it. :-) -- Wolfger http://wolfger.wordpress.com/ AOL IM: wolf4coyot Yahoo!Messenger: wolfgersilberbaer From henrik at canonical.com Thu May 8 15:52:25 2008 From: henrik at canonical.com (Henrik Nilsen Omma) Date: Thu, 08 May 2008 16:52:25 +0100 Subject: Incomplete with no response >30 days In-Reply-To: <48230823.2050104@ubuntu.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <48230823.2050104@ubuntu.com> Message-ID: <482321B9.1030005@canonical.com> Sarah Hobbs wrote: > The documentation is now updated. See > https://wiki.ubuntu.com/Bugs/HowToTriage#head-89f23324471028da4ff2dc496f0bdd299d72c093 > > > Is that unclear? Any questions, thoughts or comments? Have I missed > out any groups? I don't think it's appropriate for a developer to change the triage team's workflow policy with a wiki edit while we are still having discussions about it. We've scheduled this as a UDS topic. I've reverted your edit. Henrik From rainct at ubuntu.com Thu May 8 16:25:01 2008 From: rainct at ubuntu.com (Siegfried Gevatter (RainCT)) Date: Thu, 8 May 2008 18:25:01 +0200 Subject: Incomplete with no response >30 days In-Reply-To: <357b51820805080922s2abbd0f5yb6395163de6a019@mail.gmail.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <48230823.2050104@ubuntu.com> <482321B9.1030005@canonical.com> <357b51820805080922s2abbd0f5yb6395163de6a019@mail.gmail.com> Message-ID: <357b51820805080925mb8e2716meaa8f10d52a8a6be@mail.gmail.com> 2008/5/8 Henrik Nilsen Omma : > I don't think it's appropriate for a developer to change the triage > team's workflow policy with a wiki edit while we are still having > discussions about it. We've scheduled this as a UDS topic. Hm... Where is there the change? Triagers are currently supposed to don't touch those bugs. Getting into the discussion, I don't sympathise with the idea of using "In Progress" (as it would conflict with what it's already used for now, to indicate that a developer is working on it "right now"). I can however think of some changes; for example, instead of using "New" for not-yet-approved sync requests, those could be set to "Confirmed", and the status to indicate to archive admins that they have been approved by a developer could be "Triaged" (with this change we would archive: a) reducing confusion, I've seen triagers confirming sync requests that would fix bugs; b) get sync requests out of the "New" bugs list; c) reduce the amount of people who can set the approved status to developers and ubuntu-bugcontrol members, who should be experienced enough to know if they are supposed to change the status to "Triaged" or not). Just my 5 cent, -- Siegfried-Angel Gevatter Pujals (RainCT) GNU/Linux User #438657. Ubuntu User #11680. From siretart at ubuntu.com Fri May 23 10:31:58 2008 From: siretart at ubuntu.com (Reinhard Tartler) Date: Fri, 23 May 2008 12:31:58 +0200 Subject: Triaging xine-lib bugs Message-ID: <87abih71lt.fsf@faui44a.informatik.uni-erlangen.de> In order to deal with the bugs in the xine-lib package, I did write some guidelines how to triage the crashers bug in a wiki page. I would really appreciate if the bugsquad people could look at these notes, clean it up and properly integrate them with the official debugging procedures. Please note that it is xine-lib specific, I think the instruction could be worded in a more general way, so that it applies to our other media packages, including mplayer, vlc, ffmpeg and nearly anything that uses ffmpeg to play a movie. Source can be found https://wiki.ubuntu.com/ReinhardTartler/DebuggingXineLib, included inline here for easy commenting (sorry for the long lines): = Dealing with Xine-Lib Bugs = Currently on https://launchpad.net/ubuntu/+source/xine-lib/+bugs, many of the bugs are actually crasher bugs, that are pretty difficult to deal with. In order to be able to deal with them, we need pretty precise information on the cause of the bug. In previous ubuntu releases, we have been providing debug symbols only using ddebs. These ddebs are not availble in PPA archives, so that we cannot produce the same meaningful backtraces with backported test packages. In order to fix that, the packages in intrepid (and its backports) provide debug symbols themselves. = How can triagers help = Dear triagers, if you notice a crasher bug, please make sure that the bug is complete. Please set the bug to incomplete until the following pieces of information are provided: * example file that causes the crash * exact versions used * a backtrace using the latest packages from the motumedia PPA. = Stock Response for xine-lib bugs = Thanks for taking your time to report this bug. You have reported a crash in the xine-lib library. In order to be able to actually fix this bug, we must be able to * reproduce it * check if it happens with the latest version * understand where it actually crashes You can help with the first point by attaching an example file to this bug report. Please note that a proper attachment is preferred over a link to some remote site. Remote side that are password protected or otherwise restriced (like services like rapidshare.com and similar) are absolutely not acceptable. For the 2nd point, the MOTUMedia team provide updated packages for xine-lib and ffmpeg in their PPA for past ubuntu releases. See http://launchpad.net/~motumedia/+archive for instructions how to enable that archive. Please add this repository to your /etc/apt/sources.list, update your system and make sure, that you have both packages 'ffmpeg-dbg' and 'libxine1-dbg' installed (use 'sudo apt-get dist-upgrade && sudo apt-get install libxine1-dbg ffmpeg-dbg'). This way, you can produce meaningful backtraces that help us with point 3. You can read https://wiki.ubuntu.com/Backtrace about how to create proper backtraces that help developers identifying the exact location of the crash. Thank you for your cooperation. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From siretart at ubuntu.com Sat May 24 11:58:15 2008 From: siretart at ubuntu.com (Reinhard Tartler) Date: Sat, 24 May 2008 13:58:15 +0200 Subject: Incomplete with no response >30 days References: <481EC0A7.2000104@ubuntu.com> <4196803.26751209975899539.JavaMail.root@zimbra> Message-ID: <878wxzgbhk.fsf@faui44a.informatik.uni-erlangen.de> Johnathon Tinsley writes: >> ubuntu-archive, ubuntu-{universe,main}-sponsors, or motu-release >> subscribed, please leave those bugs alone. >> >> They're not filed by users only, and developers have almost always >> looked at the bugs, if not filed them themselves. They have a special >> sequence of steps to be followed, and the bug squad interfering with >> them is not helpful. > > If you really want triagers to leave your bugs alone, you need to have > a tag, or something. I can't see from that bug that it is anything to > do with devs, its _not obvious_. The bug state was Incomplete, with no > assignee, which means to us that its still in a triage state. I'm sorry, but I may have misunderstood something. I thought the point of the bugsquad team was to make the live of developers easier and not more complicated. Clearly these bugs cause misunderstanding on the bugsquad team. I therefore thing these type of bugs need to be discussed with the developers who have to work with them (which basically means all developers). Since you cannot expect all developers to read this mailing list, I'd suggest starting that discussion on ubuntu-devel. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From siretart at ubuntu.com Sat May 24 12:03:55 2008 From: siretart at ubuntu.com (Reinhard Tartler) Date: Sat, 24 May 2008 14:03:55 +0200 Subject: Bugs with status 'In Progress' without assignee Message-ID: <871w3rgb84.fsf@faui44a.informatik.uni-erlangen.de> According to https://wiki.ubuntu.com/Bugs/Status, bugs with status 'In Progress' "should" have an assignee. According to http://tinyurl.com/5mvws2 there are currently about ~200 of such bugs. I clearly don't see the point in having such bugs. Could you please give me a valid use case for this? If there is none, I suggest to set all of them to triaged. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From jw+debian at jameswestby.net Sat May 24 15:05:09 2008 From: jw+debian at jameswestby.net (James Westby) Date: Sat, 24 May 2008 17:05:09 +0200 Subject: Incomplete with no response >30 days In-Reply-To: <48219F3C.8090508@canonical.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> Message-ID: <1211641509.6483.2.camel@flash> Hi all, After some discussion at UDS the documentation was added back to the page, and was marked as being a draft, which everyone thought was satisfactory until a more permanent solution can be found. We also discussed what the solution should be. ScottK is going to mail the ubuntu-devel-discuss with the proposal that we came up with. If that is accepted then the changes will be announced here. Thanks, James From hggdh2 at gmail.com Sat May 24 16:48:47 2008 From: hggdh2 at gmail.com (HggdH) Date: Sat, 24 May 2008 11:48:47 -0500 Subject: Incomplete with no response >30 days In-Reply-To: <1211641509.6483.2.camel@flash> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> Message-ID: <1211647727.6661.5.camel@localhost> > We also discussed what the solution should be. ScottK is going > to mail the ubuntu-devel-discuss with the proposal that we came > up with. If that is accepted then the changes will be announced > here. I am not quite sure I understand. So the proposal will be discussed by developers without input from triagers? Frankly, I do not agree. Since I think this will start another heavy discussion, I am also copying ubuntu-devel-discuss here. But, certainly, alienating bug-squad is not right. ..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 wolfger at gmail.com Sat May 24 18:23:37 2008 From: wolfger at gmail.com (Wolfger) Date: Sat, 24 May 2008 14:23:37 -0400 Subject: Bugs with status 'In Progress' without assignee In-Reply-To: <871w3rgb84.fsf@faui44a.informatik.uni-erlangen.de> References: <871w3rgb84.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <3b00b3330805241123m60ede958y5a6d7c02ffeb2c62@mail.gmail.com> On Sat, May 24, 2008 at 8:03 AM, Reinhard Tartler wrote: > > According to https://wiki.ubuntu.com/Bugs/Status, bugs with status 'In > Progress' "should" have an assignee. According to > http://tinyurl.com/5mvws2 there are currently about ~200 of such bugs. > > I clearly don't see the point in having such bugs. Could you please give > me a valid use case for this? > > If there is none, I suggest to set all of them to triaged. Only reason I can see for this is that "in progress" is a status anybody can use, and "triaged" is not. Still, I don't think it's proper to have a bug "in progress" without an assignee. -- Wolfger http://wolfger.wordpress.com/ My 5 today: #90080 (macchanger), #150557 (linux-source-2.6.20), #75818 (linux-source-2.6.15), #68329 (pbuilder), #185480 (octave3.0) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day From hobbsee at ubuntu.com Sun May 25 08:33:38 2008 From: hobbsee at ubuntu.com (Sarah Hobbs) Date: Sun, 25 May 2008 18:33:38 +1000 Subject: Incomplete with no response >30 days In-Reply-To: <1211647727.6661.5.camel@localhost> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> Message-ID: <48392462.9080106@ubuntu.com> HggdH wrote: >> We also discussed what the solution should be. ScottK is going >> to mail the ubuntu-devel-discuss with the proposal that we came >> up with. If that is accepted then the changes will be announced >> here. > > I am not quite sure I understand. So the proposal will be discussed by > developers without input from triagers? Frankly, I do not agree. > > Since I think this will start another heavy discussion, I am also > copying ubuntu-devel-discuss here. But, certainly, alienating bug-squad > is not right. > > ..hggdh.. > > Whoever said that the bug triagers could not contribute to -devel-discuss? For that matter, whoever said that they do not do so already? But, again, i'd point out what Reinhart has eloquently said: > I'm sorry, but I may have misunderstood something. I thought the point > of the bugsquad team was to make the live of developers easier and not > more complicated. > > Clearly these bugs cause misunderstanding on the bugsquad team. I > therefore thing these type of bugs need to be discussed with the > developers who have to work with them (which basically means all > developers). Since you cannot expect all developers to read this mailing > list, I'd suggest starting that discussion on ubuntu-devel. > There seems to be an attitude of "screw the developers, we are the mighty bug squad, and can do what we like" here. But really, isn't the job of the bug squad to get bugs into a good state of triage, so they can be dealt with by the developers? Does it not make sense, therefore, to listen to what the developers want the bug squad to do to the bugs, in a general sense, and then for the bug squad to go away and deal with the specifics? I don't think the bug squad should have the right to say "we will make the rules, everyone else must follow them", as, while there are many bug squad people (yes, developers are still bug squad too), the bug squad does not put real bugs (ie, not invalid, etc) in a final state, so someone always has to come after them, and touch the bugs afterwards. This is not the case for developers. For those who are interested in getting the bugs into a final, finished state, in the bug squad, you may want to look at becoming developers yourselves. Just my AUD $0.02, from another fellow member of the bug squad and developer 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 sense at qense.nl Sun May 25 09:05:49 2008 From: sense at qense.nl (sense at qense.nl) Date: Sun, 25 May 2008 11:05:49 +0200 Subject: Incomplete with no response >30 days In-Reply-To: <48392462.9080106@ubuntu.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> Message-ID: <20080525110549.70he2kvtvk4kscs@www.qense.nl> Quoting Sarah Hobbs : > HggdH wrote: >>> We also discussed what the solution should be. ScottK is going >>> to mail the ubuntu-devel-discuss with the proposal that we came >>> up with. If that is accepted then the changes will be announced >>> here. >> >> I am not quite sure I understand. So the proposal will be discussed by >> developers without input from triagers? Frankly, I do not agree. >> >> Since I think this will start another heavy discussion, I am also >> copying ubuntu-devel-discuss here. But, certainly, alienating bug-squad >> is not right. >> >> ..hggdh.. >> >> > Whoever said that the bug triagers could not contribute to > -devel-discuss? For that matter, whoever said that they do not do so > already? > > But, again, i'd point out what Reinhart has eloquently said: > >> I'm sorry, but I may have misunderstood something. I thought the point >> of the bugsquad team was to make the live of developers easier and not >> more complicated. >> >> Clearly these bugs cause misunderstanding on the bugsquad team. I >> therefore thing these type of bugs need to be discussed with the >> developers who have to work with them (which basically means all >> developers). Since you cannot expect all developers to read this mailing >> list, I'd suggest starting that discussion on ubuntu-devel. >> > > There seems to be an attitude of "screw the developers, we are the > mighty bug squad, and can do what we like" here. > > But really, isn't the job of the bug squad to get bugs into a good > state of triage, so they can be dealt with by the developers? Does it > not make sense, therefore, to listen to what the developers want the > bug squad to do to the bugs, in a general sense, and then for the bug > squad to go away and deal with the specifics? > > I don't think the bug squad should have the right to say "we will make > the rules, everyone else must follow them", as, while there are many > bug squad people (yes, developers are still bug squad too), the bug > squad does not put real bugs (ie, not invalid, etc) in a final state, > so someone always has to come after them, and touch the bugs > afterwards. This is not the case for developers. > > For those who are interested in getting the bugs into a final, finished > state, in the bug squad, you may want to look at becoming developers > yourselves. > > Just my AUD $0.02, from another fellow member of the bug squad and developer > > Hobbsee I agree the Bugsquad sometimes forget they're not the only one here. But the developers sometimes also forget that. We're not the humble servant of the developers, although during some discussions I felt like we were being treated like that. (Of course not everyone does that, and there are also people in the bugsquad that behaved like that(maybe I even sounded so).) We should discuss this together, as equals. We need each other. We also should discuss this together and listen to each other. And yes, maybe the Bugsquad should be the group that adapts the most to the developers. But we shouldn't do exactly as told. I'm against having this discussion at devel-discuss. Not all bugsquad members are subscribed to that and it sounds a bit like the developers are thinking what's the best for us. But if we get a dozen exceptions more to cope with I think the bug triaging will become slower and less popular resulting in more open bugs and less complete bugs for the developers. We should just be nice to each other. Don't bitch, get angry or run away in a discussion. The only problem is where to have the discussion. Maybe we should create a separate mailist for workflows and triaging policies. I think this subject is important enough to get an own mailist. Sense Hofstede (Maybe I sound a bit rude. I'm sorry for that. Please don't forget I'm a 15 year old Dutch boy, so I can get the nuances wrong. And when you aren't talking with people while standing in front of them, things are easier misunderstood.) From nalimilan at club.fr Sun May 25 10:31:40 2008 From: nalimilan at club.fr (Milan Bouchet-Valat) Date: Sun, 25 May 2008 12:31:40 +0200 Subject: Incomplete with no response >30 days In-Reply-To: <48392462.9080106@ubuntu.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> Message-ID: <1211711500.21873.15.camel@milan> Le dimanche 25 mai 2008 à 18:33 +1000, Sarah Hobbs a écrit : > There seems to be an attitude of "screw the developers, we are the > mighty bug squad, and can do what we like" here. The contrary can be true as well, but that's absolutely not the point here. ;-) > But really, isn't the job of the bug squad to get bugs into a good state > of triage, so they can be dealt with by the developers? Does it not > make sense, therefore, to listen to what the developers want the bug > squad to do to the bugs, in a general sense, and then for the bug squad > to go away and deal with the specifics? > > I don't think the bug squad should have the right to say "we will make > the rules, everyone else must follow them", as, while there are many bug > squad people (yes, developers are still bug squad too), the bug squad > does not put real bugs (ie, not invalid, etc) in a final state, so > someone always has to come after them, and touch the bugs afterwards. > This is not the case for developers. I don't see the need here to oppose bug triager and developers here - yes, developers are members of the bug squad too, and the only aim of all these groups is to make Ubuntu work right. For this we need rule the best cooperation between all classes of contributors. And bug triagers are a really diverse group, from which you cannot expect to master every Ubuntu trick. The bug squad is not here to serve developers, but precisely to get needed information so that bugs are made useful to them. Developers also should make the life of bug triagers easier since their own work depends on the bug squad efficiency. As Henrik Nilsen Omma summed it up [1], there's just a need to find better conventions in order to make special bugs (sync requests...) conform to the general convention. No need to hurt anyone here: developers could simply use "Confirmed" instead of "Incomplete" when waiting for more information that *they will get by themselves*, and not from any user; "Triaged" and "In progress" are still here for more advanced states. And surely assigning bugs when somebody is taking care of a bug, even if no work is going on would help, since other developers that may want to work on the bug will know what kind of "special tricks" are involved. Hope we can find a common rule 1: http://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-May/000854.html From ubuntu at kitterman.com Sun May 25 14:17:57 2008 From: ubuntu at kitterman.com (Scott Kitterman) Date: Sun, 25 May 2008 10:17:57 -0400 Subject: Incomplete with no response >30 days In-Reply-To: <1211711500.21873.15.camel@milan> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> <1211711500.21873.15.camel@milan> Message-ID: <71175-SnapperMsgD8DB99B6C45F25A2@[75.199.237.25]> On Sun, 25 May 2008 12:31:40 +0200 Milan Bouchet-Valat wrote: >Le dimanche 25 mai 2008 à 18:33 +1000, Sarah Hobbs a écrit : > >> There seems to be an attitude of "screw the developers, we are the >> mighty bug squad, and can do what we like" here. >The contrary can be true as well, but that's absolutely not the point >here. ;-) > >> But really, isn't the job of the bug squad to get bugs into a good state >> of triage, so they can be dealt with by the developers? Does it not >> make sense, therefore, to listen to what the developers want the bug >> squad to do to the bugs, in a general sense, and then for the bug squad >> to go away and deal with the specifics? >> >> I don't think the bug squad should have the right to say "we will make >> the rules, everyone else must follow them", as, while there are many bug >> squad people (yes, developers are still bug squad too), the bug squad >> does not put real bugs (ie, not invalid, etc) in a final state, so >> someone always has to come after them, and touch the bugs afterwards. >> This is not the case for developers. >I don't see the need here to oppose bug triager and developers here - yes, developers are members of the bug squad too, and the only aim of all these groups is to make Ubuntu work right. For this we need rule the best cooperation between all classes of contributors. And bug triagers are a really diverse group, from which you cannot expect to master every Ubuntu trick. > >The bug squad is not here to serve developers, but precisely to get >needed information so that bugs are made useful to them. Developers also >should make the life of bug triagers easier since their own work depends >on the bug squad efficiency. > >As Henrik Nilsen Omma summed it up [1], there's just a need to find >better conventions in order to make special bugs (sync requests...) >conform to the general convention. No need to hurt anyone here: >developers could simply use "Confirmed" instead of "Incomplete" when >waiting for more information that *they will get by themselves*, and not >from any user; "Triaged" and "In progress" are still here for more >advanced states. And surely assigning bugs when somebody is taking care >of a bug, even if no work is going on would help, since other developers >that may want to work on the bug will know what kind of "special tricks" >are involved. > >Hope we can find a common rule > > At UDS we had a couple of good sessions around this topic. I accepted an action, as one of the people primarily focused on development present, to summarize the proposal to the development community. I don't think that was meant to imply that people focused on triaging should be left out, just that it wasn't my task to communicate it to them (on a related note, if someone reading this on -devel-discuss could let this onto the bugsquad list, please do as I'm not subscribed). Rather than develop more alternate solutions, I'd suggest patience at rhis point. It will likely take a little bit for me get this written up as the proposal has some complexity to it and I need to write out enough background to make it clear what problems we are trying to solve with the proposed change for those who have not been involved in the discussion thus far. Scott K From hggdh2 at gmail.com Sun May 25 15:02:37 2008 From: hggdh2 at gmail.com (HggdH) Date: Sun, 25 May 2008 10:02:37 -0500 Subject: Incomplete with no response >30 days In-Reply-To: <48392462.9080106@ubuntu.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> Message-ID: <1211727757.25113.18.camel@localhost> On Sun, 2008-05-25 at 18:33 +1000, Sarah Hobbs wrote: > Whoever said that the bug triagers could not contribute to > -devel-discuss? For that matter, whoever said that they do not do so > already? You got me. I do not know who said that. I know, though, that I am trying to keep triagers in the discussion. > There seems to be an attitude of "screw the developers, we are the > mighty bug squad, and can do what we like" here. > Sarah, please do not put in my mouth what I did *not* say. I do not know what other problems you have been having, but I am sure I *never* said such a stupidity. Let me re-state what I said: "I am not quite sure I understand. So the proposal will be discussed by developers without input from triagers?" > But really, isn't the job of the bug squad to get bugs into a good state > of triage, so they can be dealt with by the developers? Indeed. This is what we all want. > Does it not > make sense, therefore, to listen to what the developers want the bug > squad to do to the bugs, in a general sense, and then for the bug squad > to go away and deal with the specifics? No. It does not. It does make sense for *BOTH* developers and bug-squadders to discuss and reach a consensus. We do not impose on YOU how to develop, you should not impose on us how to triage. But we can reach a consensus. And the triagers will not go away, no matter how much you would like them to. > I don't think the bug squad should have the right to say "we will make > the rules, everyone else must follow them", as, while there are many bug > squad people (yes, developers are still bug squad too), the bug squad > does not put real bugs (ie, not invalid, etc) in a final state, so > someone always has to come after them, and touch the bugs afterwards. > This is not the case for developers. Again, I never said that -- YOU say it. What I said is I see no sense on having a discussion on how to triage done exclusively in the devel-discuss, and then presenting the triagers on what has been decided. There is a mailing list devoted to triaging. I see no problem in having the discussion in devel-discuss *and* on bugsquad (even if this means duplication): all affected areas will be able to immediately participate. But I still fail to understand why the discussion would be restricted to devel-discuss, a forum for developers, not for triagers. > > For those who are interested in getting the bugs into a final, finished > state, in the bug squad, you may want to look at becoming developers > yourselves. OK. So now I find that it is not the "mighty" triagers, but the "mighty developers"? > Just my AUD $0.02, from another fellow member of the bug squad and developer Ditto here, from someone who has done both development and triaging/support for some quite long years. I am not as ignorant as you may think. It is a pity that this discussion escalated so fast to the makings of a flame war. ..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 hobbsee at ubuntu.com Sun May 25 16:04:10 2008 From: hobbsee at ubuntu.com (Sarah Hobbs) Date: Mon, 26 May 2008 02:04:10 +1000 Subject: Incomplete with no response >30 days In-Reply-To: <1211727757.25113.18.camel@localhost> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> <1211727757.25113.18.camel@localhost> Message-ID: <48398DFA.6000102@ubuntu.com> HggdH wrote: > No. It does not. It does make sense for *BOTH* developers and > bug-squadders to discuss and reach a consensus. We do not impose > on YOU how to develop, you should not impose on us how to triage. Telling you how to triage? No. Finding a way of saying "you do not need to waste your time on these bugs, because these have special procedures and different definitions of things, and feel free to focus on other bugs" - I guess you could interpret that as telling you how to triage, at a stretch. On the other hand, isn't it better for you guys that way, so you end up with a higher final count of bugs that are looked at in a given time period? Doesn't that make the bug squad more effective? > It is a pity that this discussion escalated so fast to the makings of a > flame war. I would hope that could be avoided. As a general note, I was not putting words into your mouth - I was commenting more on what some of the general perceptions seem to be, from within the bug squad. Unfortunately, the last 'consensus' I saw was a wiki revert (which, I now see has been added back, with a great section of 'draft' around it), and when attempting to discuss the ways forward with some high members of the bug squad, some MOTUs effectively got responses of "we don't approve of using the bug tracker for workflow bugs, as they're not real bugs, so you guys have to figure out a way of making it work the way you guys want it to, without us changing, because there are more triagers than developers, so it's more feasible for you guys to change your workflow than us". I would hope that a mailing list is more effective than the irc-based discussions were. It being on both mailing lists, so both groups of people see it, should help with that. Needless to say, I'll hearby assume that the above comments some of the developers got from the bug squad are *not* the norm - and from these mails, it would appear that there is a reasonable chance of mediation, rather than the earlier vibes coming from certain members of the bug squad team. 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 daniel.holbach at ubuntu.com Mon May 26 14:02:01 2008 From: daniel.holbach at ubuntu.com (Daniel Holbach) Date: Mon, 26 May 2008 16:02:01 +0200 Subject: Patch Statuses in Launchpad Message-ID: <483AC2D9.40701@ubuntu.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everybody, in the "Universe QA" session at UDS we discussed handling of patches in Launchpad. https://launchpad.net/ubuntu/+bugs?field.has_patch=on currently has 2159 on it and it's particularly frustrating to review that list because some of the patches were already rejected, some need more work, etc. We had Björn Tillenius in the session who let us know that there's no immediate goal of adding "patch status" functionality to Malone. During the session we discussed the usage of tags to indicate what kind of action is necessary. I propose the following usage to make our lifes easier until Launchpad has grown its own patch handling: - don't mass-tag bugs with patches, instead assume that a review is necessary if none of the tags below are used, - use "patch-needs-work" if you reviewed a patch and it needs more work (or you flat-out rejected it) - use "patch-went-upstream" if you forwarded it upstream to get their input before uploading it to Ubuntu The benefits are obvious: - we have a way coordinating our efforts - make "bugs-with-patches-attached ZERO" an achievable goal - don't mass-tag loads of bugs - don't delete patch attachments in bugs to keep track of stuff - distinguish between bug status and patch status (ie: patch might be applied already, but bug is 'incomplete' because feedback is missing, etc) - This would make lists like really-fix-it far more usable The downsides are the following: - What about bugs with more than one patch attached (more than one task)? Do we just stick to the "if no tag is set, review is required" rule? - AFAIK there's no Malone way to ask for all bugs that don't have a tag set [1]. Did I miss any use-cases? What do you think? Have a nice day, Daniel [1] This script helps though: >>> import urllib >>> bwpa = set(map(lambda a: int(a), urllib.urlopen("http://launchpad.net/ubuntu/+bugs-text?field.has_patch=on"))) >>> bwptnw = set(map(lambda a: int(a), urllib.urlopen("http://launchpad.net/ubuntu/+bugs-text?field.tag=patch-needs-work"))) >>> print len(bwpa.difference(bwptnw)) - -- My 5 today: #234477 (pidgin), #230016, #234457 (ygraph), #234468 (roxen4), #234113 (icepick) 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 iD8DBQFIOsLYRjrlnQWd1esRAheXAJ9Ah9beqPClEOaCFaJWa6+MESDrvACcDw5R srU2G1hxKHmwQecLd9ao/2U= =TvXL -----END PGP SIGNATURE----- From daniel.holbach at ubuntu.com Mon May 26 14:32:17 2008 From: daniel.holbach at ubuntu.com (Daniel Holbach) Date: Mon, 26 May 2008 16:32:17 +0200 Subject: Patch Statuses in Launchpad In-Reply-To: <20080526141957.GC5453@bee.dooz.org> References: <483AC2D9.40701@ubuntu.com> <20080526141957.GC5453@bee.dooz.org> Message-ID: <483AC9F1.2030707@ubuntu.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Loïc Minier schrieb: > Did you consider removing the "patch" flag? This is a bit of a hack, > but at least this works on a per patch basis and doesn't hurt AFAIK. I did and recommended doing that for "getting stuff off the really-fix-it list", I just think that we'd do better with a more fine-grained approach, where we can say more about the state of the patches and could support more workflows. You're right though about the "per patch basis" bit. Also I think it might be a good idea to start a https://wiki.ubuntu.com/MaloneHacks page so we do better at feeding back our experience with Malone and let the Launchpad Bugs Team know how we use the bug tracker. Have a nice day, Daniel - -- My 5 today: #234477 (pidgin), #230016, #234457 (ygraph), #234468 (roxen4), #234113 (icepick) 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 iD8DBQFIOsnxRjrlnQWd1esRAkojAJ9MtN5X9LhWa2SCB2Fl4IpBtUIouQCffHQw B2Os5X3XHyPeZcFzBXLjmFo= =4YoI -----END PGP SIGNATURE----- From siretart at ubuntu.com Mon May 26 15:53:18 2008 From: siretart at ubuntu.com (Reinhard Tartler) Date: Mon, 26 May 2008 17:53:18 +0200 Subject: Incomplete with no response >30 days References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> <20080525110549.70he2kvtvk4kscs@www.qense.nl> Message-ID: <874p8ldpu9.fsf@faui44a.informatik.uni-erlangen.de> sense at qense.nl writes: > I agree the Bugsquad sometimes forget they're not the only one here. > But the developers sometimes also forget that. We're not the humble > servant of the developers, although during some discussions I felt > like we were being treated like that. Let's me look up the description of the bugsquad from https://wiki.ubuntu.com/BugSquad: : The Ubuntu Bug Squad is an essential asset in helping to make Ubuntu and : its derivatives better. : The Bug Squad is the first point of contact for the bugs filed about : Ubuntu. They assign bugs to packages, ensure that bug reports are : complete, find duplicate bug reports, recreate bugs and forward bugs to : their upstream authors. All of these activities help the bug get fixed : and subsequently making Ubuntu even better. So the bugsquad does not seem to be willing to actually fix the bugs. Which is more or less fine with me, it seems that this way is easier to attract people to work on triaging bugs than encouraging them to become developer themselves and actually fix them. However, in the end, we all want the bugs to be fixed. And this is getting more complicated if the bugsquad does things that intervenes with the developers work. And editing bugs without understanding them is a severe intervention, because it causes confusion on both the reporters and the developers side. So a pretty please with sugar on the top: If you don't understand what a bug is about, please do not touch it. This includes all what is recently called a "workflow bug". I'm a bit surprised that the bugsquad team focuses on triaging and editing bugs instead on generating statistics, showing trends and pointing to pointless bug statuses like bugs marked 'in progress' without assignee or bugs assigned to a team. > We should discuss this together, as equals. We need each other. We > also should discuss this together and listen to each other. Developers don't need a group of people malicously editing their bugs, causing them additional work. Developers are very grateful to everyone who work on saving them time. If you want to discuss with developers how to work on bugs, I'd suggest talking to them. This is most effectively done on ubuntu-devel at l.u.c. If you want to CC bugsquad, that's fine for me. > And yes, maybe the Bugsquad should be the group that adapts the most > to the developers. But we shouldn't do exactly as told. I disagree here. If there is a group of people randomly and cluelessly editing bugs, they must be stopped in order to enable developers to work effectivly. I don't have the impression that the bugsquad is such an group, at least not yet. However the arguments you rised in your mail could be interpreted this way. That's why this email is so harsh. So please, again, think about the bug when working on it. If you are unsure, please contact an developer and ask for help. You shouldn't be afraid of talking to an developer. Ask developers in IRC or via email. And do notify developers how you expect interaction to be. Don't expect developers (or anyone) to regularily poll the wiki page. Do send announcements on how you intend to work on bugs. I think you get the idea. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From daniel.holbach at ubuntu.com Mon May 26 16:19:41 2008 From: daniel.holbach at ubuntu.com (Daniel Holbach) Date: Mon, 26 May 2008 18:19:41 +0200 Subject: Patch Statuses in Launchpad In-Reply-To: <87ve11cag6.fsf@faui44a.informatik.uni-erlangen.de> References: <483AC2D9.40701@ubuntu.com> <87ve11cag6.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <483AE31D.8040504@ubuntu.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Reinhard Tartler schrieb: > How would you see bugs with patches but without the tag > 'patch-needs-work'? I answered that question in my initial mail. > I'd say let's do it the other way round: Bugs with proper patches should > have the tag 'patch-needs-review'. If a developer finds a patch not > acceptable, he can remove the tag. If the patch is good and ready to be > uploaded, he should upload a package with the bug and close the bug. If > he decides it should go to upstream first, replace the patch with > 'patch-under-upstream-review' or something. The problem is: do we expect everybody who attached a patch to know about the tag and use it? What do we do about the 2100 bugs that have patches attached? Tag them all by hand? Have a nice day, Daniel - -- My 5 today: #232397 (xplanet), #232425 (system-tools-backends), #232227 (policykit), #232359 (ampache), #232311 (engauge-digitizer) 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 iD8DBQFIOuMdRjrlnQWd1esRAvJBAJ99jdIFxt2rJ8xMMqVd6P+Ey0UlyACdEO+g G1iBamNlbkgYtvTp7tRVNtw= =XmXl -----END PGP SIGNATURE----- From daniel.holbach at ubuntu.com Mon May 26 16:23:32 2008 From: daniel.holbach at ubuntu.com (Daniel Holbach) Date: Mon, 26 May 2008 18:23:32 +0200 Subject: Patch Statuses in Launchpad In-Reply-To: <71900-SnapperMsgD8DB99B6C46086DB@[75.223.205.250]> References: <483AC2D9.40701@ubuntu.com> <20080526141957.GC5453@bee.dooz.org> <71900-SnapperMsgD8DB99B6C46086DB@[75.223.205.250]> Message-ID: <483AE404.6070003@ubuntu.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Scott Kitterman schrieb: > This is what I've always done. If a patch is attached that I review and it needs wore work, I just uncheck patch and it drops off the list until an updated patch is attached. I think this simple approach is vastly preferable to a comple tag system I'll never be able to remember)se reliably. The problem with that is that after the attachment type change we have no information about the bug any more. It goes from "here's a possible solution" to "we didn't want it on the solutions list because of some reason". Having a "these are solution that need to be validated by upstream" list or "if you're interested in help improving the proposed solution" list would gain us much more. Have a nice day, Daniel - -- My 5 today: #232397 (xplanet), #232425 (system-tools-backends), #232227 (policykit), #232359 (ampache), #232311 (engauge-digitizer) 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 iD8DBQFIOuQERjrlnQWd1esRAl6DAJ4oJ/ozw6lKdnFk9N6qfm6JnRg+wgCffeZC y6OL8Qil1GikeIvGreAA/i0= =izNA -----END PGP SIGNATURE----- From hggdh2 at gmail.com Mon May 26 16:58:37 2008 From: hggdh2 at gmail.com (HggdH) Date: Mon, 26 May 2008 11:58:37 -0500 Subject: Incomplete with no response >30 days In-Reply-To: <874p8ldpu9.fsf@faui44a.informatik.uni-erlangen.de> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> <20080525110549.70he2kvtvk4kscs@www.qense.nl> <874p8ldpu9.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <1211821117.8993.54.camel@localhost> > sense at qense.nl writes: > > Let's me look up the description of the bugsquad from > https://wiki.ubuntu.com/BugSquad: > > : The Ubuntu Bug Squad is an essential asset in helping to make Ubuntu and > : its derivatives better. > > : The Bug Squad is the first point of contact for the bugs filed about > : Ubuntu. They assign bugs to packages, ensure that bug reports are > : complete, find duplicate bug reports, recreate bugs and forward bugs to > : their upstream authors. All of these activities help the bug get fixed > : and subsequently making Ubuntu even better. > > So the bugsquad does not seem to be willing to actually fix the > bugs. Which is more or less fine with me, it seems that this way is > easier to attract people to work on triaging bugs than encouraging them > to become developer themselves and actually fix them. > However, in the end, we all want the bugs to be fixed. And this is > getting more complicated if the bugsquad does things that intervenes > with the developers work. And editing bugs without understanding them is > a severe intervention, because it causes confusion on both the reporters > and the developers side. > > So a pretty please with sugar on the top: If you don't understand what a > bug is about, please do not touch it. This includes all what is recently > called a "workflow bug". And it went pretty much this way the whole email. So, developers, pretty please with sugar on top: do *not* diss down other people. All I got from this email was "we are the mighty developers, you are nothing". I was trying to help find a common (hey Reinhard, there is this word, "common") ground. I give up. ..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 yuriy.kozlov at gmail.com Mon May 26 17:48:52 2008 From: yuriy.kozlov at gmail.com (Yuriy Kozlov) Date: Mon, 26 May 2008 13:48:52 -0400 Subject: Incomplete with no response >30 days In-Reply-To: <874p8ldpu9.fsf@faui44a.informatik.uni-erlangen.de> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> <20080525110549.70he2kvtvk4kscs@www.qense.nl> <874p8ldpu9.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <714626160805261048m1c9e950fu665d2bc996011f31@mail.gmail.com> > However, in the end, we all want the bugs to be fixed. And this is > getting more complicated if the bugsquad does things that intervenes > with the developers work. And editing bugs without understanding them is > a severe intervention, because it causes confusion on both the reporters > and the developers side. > > So a pretty please with sugar on the top: If you don't understand what a > bug is about, please do not touch it. This includes all what is recently > called a "workflow bug". > I was going to post a rant (ok, still will) about making proper use of the statuses, then I finally looked at the original bug in question, and looks to me like Incomplete was the right status and this really is a case of **"If you don't understand what a bug is about, please do not touch it."** That said, responses from developers in this thread do seem to imply that once they are working on something, bug status is ignored, as well as some disrespect for people trying to help them out and learning. Bug statuses and the other tools available in Malone, such as tags, let *everybody* know what's going on. Not using them or abusing them makes things confusing for the reporter, any other user looking at the bug, bug squaders looking to help, new developers looking to help, other developers, and they can even be useful to the developer working on the bug if they have a lot on their plate. Using the given example, bugs that are marked In Progress but not assigned to anyone (nothing wrong with being assigned to a team) are silly and confusing. Using sensible uniform conventions throughout the process keeps the machine working efficiently. Workflow bugs are great, the bug tracker is a good way to keep track of things and it lets others know what's going on, if you use it properly. But there is no reason they can't fit into the rest of the system. And if they really, really don't (and I don't think that's the case. Again, in this particular case, the triager probably shouldn't have messed with a report he didn't understand) then put some form of disclaimer on top. And greasemonkey scripts[1] don't count! Yes, the point of the bug squad is to make it easier for developers to actually fix the bugs. [I assume] the bug squad guidelines were written with developer input on how to make bug reports useful to them, and eliminate the ones that aren't. If there is some convention that hurts the workflow overall, then it should be revised. But throwing them out only makes things confusing for everyone. Remember that [almost] everything on Launchpad is public and can be viewed and edited by anybody for various reasons, most of them trying to help in some way. There are 9 statuses, importance, assignee, tags, description, comments, and more tools that let you express what's going on to users, triagers, and developers. Use them. ~ Yuriy [1] https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-May/000851.html From henrik at canonical.com Mon May 26 17:49:07 2008 From: henrik at canonical.com (Henrik Nilsen Omma) Date: Mon, 26 May 2008 18:49:07 +0100 Subject: Incomplete with no response >30 days In-Reply-To: <71175-SnapperMsgD8DB99B6C45F25A2@[75.199.237.25]> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> <1211711500.21873.15.camel@milan> <71175-SnapperMsgD8DB99B6C45F25A2@[75.199.237.25]> Message-ID: <483AF813.305@canonical.com> Scott Kitterman wrote: > At UDS we had a couple of good sessions around this topic. I accepted an action, as one of the people primarily focused on development present, to summarize the proposal to the development community. I don't think that was meant to imply that people focused on triaging should be left out, just that it wasn't my task to communicate it to them (on a related note, if someone reading this on -devel-discuss could let this onto the bugsquad list, please do as I'm not subscribed). > > Rather than develop more alternate solutions, I'd suggest patience at rhis point. It will likely take a little bit for me get this written up as the proposal has some complexity to it and I need to write out enough background to make it clear what problems we are trying to solve with the proposed change for those who have not been involved in the discussion thus far. I second this sentiment. Please give this topic a break now. We had two good discussions at UDS where we looked at both communication and technical issues. The good news is that we may well end up with procedures that are better for all teams involved than what we currently have -- I look forward to reading Scott's draft proposals. Sarah's guideline have been put back while we investigate alternatives. For the record I would like to express my regret for the way I performed the wiki edit. I reverted because I objected to the bugsquad policy being changed unilaterally -- as I perceived it -- but I should have found a more sensitive way of expressing that. Making a note on the page that the topic was still being discussed or moving Sarah's changes to a discussion page would have been better. Henrik From caroline.ford.work at googlemail.com Mon May 26 18:25:43 2008 From: caroline.ford.work at googlemail.com (Caroline Ford) Date: Mon, 26 May 2008 19:25:43 +0100 Subject: Incomplete with no response >30 days In-Reply-To: <483AF813.305@canonical.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> <1211711500.21873.15.camel@milan> <71175-SnapperMsgD8DB99B6C45F25A2@75.199.237.25> <483AF813.305@canonical.com> Message-ID: 2008/5/26 Henrik Nilsen Omma : > I second this sentiment. Please give this topic a break now. We had two > good discussions at UDS where we looked at both communication and > technical issues. The good news is that we may well end up with > procedures that are better for all teams involved than what we currently > have -- I look forward to reading Scott's draft proposals. Sarah's > guideline have been put back while we investigate alternatives. Well most of us mere mortals weren't actually at the UDS and have no idea what you decided. The lack of love for the bug squad, doing hours of grunt work/support is strongly noted. Caroline From caroline.ford.work at googlemail.com Mon May 26 19:52:13 2008 From: caroline.ford.work at googlemail.com (Caroline Ford) Date: Mon, 26 May 2008 20:52:13 +0100 Subject: Fwd: Proposed changes to workflow bug management In-Reply-To: <200805261545.36643.ubuntu@kitterman.com> References: <200805261545.36643.ubuntu@kitterman.com> Message-ID: Forwarded as requested ---------- Forwarded message ---------- From: Scott Kitterman Date: 2008/5/26 Subject: Proposed changes to workflow bug management To: ubuntu-devel at lists.ubuntu.com At UDS Intrepid we had a good discussion between a few Ubuntu developers and some people who are active in bugsquad (I recognize that many developers also triage bugs. The discussion was focused on people who triage, but are not developers.). I accepted the action to present the issue and proposed solution to the development community for comment (I know bugsquad needs to discuss this too, but I'm probably not the best one to lead that discussion). This is my best attempt to capture the proposal that resulted from our discussions at UDS. I'm sure I've missed things/made mistakes. Please point them out so it can be fixed. This writeup is no doubt slanted based on my perception of the problem. No offense/insult against bugsquad is intended here. If it's present, please let me know so I can fix it. Problem: A number of development processes use bugs to track work flow. This class of bugs has unique rules and bug status has different meanings (even perhaps different meanings depending on the phase of the development cycle). This class of bugs rarely benefits from work by bugsquad (non-developer) triage efforts. In some cases changes may actually be harmful. After some review, it appears that there is no easy way for bugsquad members to reliably identify such bugs that is consistent with their normal work flow. The most reliable method to identify them by team subscription (e.g. ubuntu-archive, ubuntu-mir, ubuntun-universe-sponsors, etc.), but this is not something generally used in the triage process. Proposal: Develop a new class of private bug for workflow bugs and make such bugs private. Develop a work flow to resolve uncertainties about workflow bugs through ubuntu-bugcontrol. Rationale: The most reliable way to ensure new triagers do not involve themselves with workflow bugs is to make it so they cannot see them. Through appropriate team permissions in Launchpad, workflow bugs can be visible to those that need them. Advantages: No bugsquad process changes required (the current "Special types of bugs" section would be changed to indicate ubuntu-bugcontrol should be asked to see if the bug needs to be added to the workflow bug class if a triager believes they have found one not appropriately marked). The risk of inadvertent/incorrect changes by people not involved in the development process would be greatly reduced. Noise level changes appearing in the bugmail stream would also be reduced. Overall harmony between bugsquad and developers should be improved. Disadvantages: Some development work is needed to mechanize the proposed process changes. Ubuntu development becomes slightly less transparent. There is some risk of duplicate bugs being filed. Process change always causes some disruption. Documentation impacts: The following wiki pages will need to be updated: https://wiki.ubuntu.com/UbuntuDevelopment https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive https://wiki.ubuntu.com/UbuntuDevelopment/Merging https://wiki.ubuntu.com/MainInclusionProcess https://wiki.ubuntu.com/Bugs/HowToTriage The last page above has a draft list of types of workflow bugs: https://wiki.ubuntu.com/Bugs/HowToTriage#head-0670f256d42484d8f9d0cec896eb2c05e43388e3 Since needs-packaging bugs are generally filed by end-users they would be kept public. Development requirements/issues: 1. Some launchpad changes are likely needed to effect this change. 2. Requestsync will need to be modified. 3. Additional scripts may be useful to aid in workflow bug filing 4. Need to identify teams that would have access to workflow bugs: Bug filers always have access to a private bug, so those who are not in an appropriate team would still have access to workflow bugs they file. ubuntu-bugcontrol would have access to these bugs (ubuntu-dev is a member of this team, so it gives all developers access). universe-contributors should also be a member. One open question is, should there be an open team that has access to these bugs? Please discuss. Scott K P.S. Would someone who is subscribed please forward this to ubuntu-bugsquad. -- ubuntu-devel mailing list ubuntu-devel at lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: signature.asc URL: From yuriy-kozlov at kubuntu.org Mon May 26 20:18:41 2008 From: yuriy-kozlov at kubuntu.org (Yuriy Kozlov) Date: Mon, 26 May 2008 16:18:41 -0400 Subject: Proposed changes to workflow bug management In-Reply-To: References: <200805261545.36643.ubuntu@kitterman.com> Message-ID: <714626160805261318o53a048b9w4425aec65aafd73c@mail.gmail.com> On Mon, May 26, 2008 at 3:52 PM, Caroline Ford wrote: > Forwarded as requested > > > ---------- Forwarded message ---------- > From: Scott Kitterman > Date: 2008/5/26 > Subject: Proposed changes to workflow bug management > To: ubuntu-devel at lists.ubuntu.com > > > At UDS Intrepid we had a good discussion between a few Ubuntu developers and > some people who are active in bugsquad (I recognize that many developers also > triage bugs. The discussion was focused on people who triage, but are not > developers.). I accepted the action to present the issue and proposed > solution to the development community for comment (I know bugsquad needs to > discuss this too, but I'm probably not the best one to lead that discussion). > > This is my best attempt to capture the proposal that resulted from our > discussions at UDS. I'm sure I've missed things/made mistakes. Please point > them out so it can be fixed. This writeup is no doubt slanted based on my > perception of the problem. No offense/insult against bugsquad is intended > here. If it's present, please let me know so I can fix it. > > Problem: A number of development processes use bugs to track work flow. This > class of bugs has unique rules and bug status has different meanings (even > perhaps different meanings depending on the phase of the development cycle). > This class of bugs rarely benefits from work by bugsquad (non-developer) > triage efforts. In some cases changes may actually be harmful. > > After some review, it appears that there is no easy way for bugsquad members > to reliably identify such bugs that is consistent with their normal work > flow. The most reliable method to identify them by team subscription (e.g. > ubuntu-archive, ubuntu-mir, ubuntun-universe-sponsors, etc.), but this is not > something generally used in the triage process. > > Proposal: Develop a new class of private bug for workflow bugs and make such > bugs private. Develop a work flow to resolve uncertainties about workflow > bugs through ubuntu-bugcontrol. > > Rationale: The most reliable way to ensure new triagers do not involve > themselves with workflow bugs is to make it so they cannot see them. Through > appropriate team permissions in Launchpad, workflow bugs can be visible to > those that need them. > > Advantages: No bugsquad process changes required (the current "Special types > of bugs" section would be changed to indicate ubuntu-bugcontrol should be > asked to see if the bug needs to be added to the workflow bug class if a > triager believes they have found one not appropriately marked). The risk of > inadvertent/incorrect changes by people not involved in the development > process would be greatly reduced. Noise level changes appearing in the > bugmail stream would also be reduced. > > Overall harmony between bugsquad and developers should be improved. > > Disadvantages: Some development work is needed to mechanize the proposed > process changes. Ubuntu development becomes slightly less transparent. > There is some risk of duplicate bugs being filed. Process change always > causes some disruption. > > Documentation impacts: The following wiki pages will need to be updated: > > https://wiki.ubuntu.com/UbuntuDevelopment > https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive > https://wiki.ubuntu.com/UbuntuDevelopment/Merging > https://wiki.ubuntu.com/MainInclusionProcess > https://wiki.ubuntu.com/Bugs/HowToTriage > > The last page above has a draft list of types of workflow bugs: > > https://wiki.ubuntu.com/Bugs/HowToTriage#head-0670f256d42484d8f9d0cec896eb2c05e43388e3 > > Since needs-packaging bugs are generally filed by end-users they would be kept > public. > > Development requirements/issues: > > 1. Some launchpad changes are likely needed to effect this change. > 2. Requestsync will need to be modified. > 3. Additional scripts may be useful to aid in workflow bug filing > 4. Need to identify teams that would have access to workflow bugs: > > Bug filers always have access to a private bug, so those who are not in an > appropriate team would still have access to workflow bugs they file. > > ubuntu-bugcontrol would have access to these bugs (ubuntu-dev is a member of > this team, so it gives all developers access). universe-contributors should > also be a member. One open question is, should there be an open team that > has access to these bugs? > > Please discuss. > > Scott K > > P.S. Would someone who is subscribed please forward this to ubuntu-bugsquad. > I think this is a bad idea just based on the transparency issue. Duplicate bugs and the other disadvantages will be a problem as well. I think "Occasionally someone does something they're not supposed to, so let's hide these from everybody" is entirely the wrong approach. Why not just use a tag? or heck, write BUG SQUAD DO NOT TOUCH at the top of the description. ~ Yuriy From wolfger at gmail.com Mon May 26 22:13:36 2008 From: wolfger at gmail.com (Wolfger) Date: Mon, 26 May 2008 18:13:36 -0400 Subject: Incomplete with no response >30 days In-Reply-To: <874p8ldpu9.fsf@faui44a.informatik.uni-erlangen.de> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> <20080525110549.70he2kvtvk4kscs@www.qense.nl> <874p8ldpu9.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <3b00b3330805261513y6495e472nf9bd8ac46a35d782@mail.gmail.com> On Mon, May 26, 2008 at 11:53 AM, Reinhard Tartler wrote: > So a pretty please with sugar on the top: If you don't understand what a > bug is about, please do not touch it. This includes all what is recently > called a "workflow bug". This is a pointless request, since it requires the person looking at the bug to understand that he doesn't understand. People who think they understand (but don't) are far more damaging than people who know they don't understand. > I'm a bit surprised that the bugsquad team focuses on triaging and > editing bugs instead on generating statistics, showing trends and > pointing to pointless bug statuses like bugs marked 'in progress' > without assignee or bugs assigned to a team. I am totally confused by what you mean here. You are surprised that bugsquad focuses on triaging bugs? > Developers don't need a group of people malicously editing their bugs, Ubuntu does not need people maliciously sowing dissent in the ranks of the volunteers who work very hard to help Ubuntu. If you have evidence that "a group of people" are "maliciously" editing bugs, then please present that evidence so we can deal with these people. If you have no such evidence, then you are not doing Ubuntu any favors at all by making baseless accusations against unnamed people. In fact, I think there may be some violation of the code of conduct occurring here. > So please, again, think about the bug when working on it. If you are > unsure, please contact an developer and ask for help. You shouldn't be > afraid of talking to an developer. After some of the lovely attitudes I've seen in this thread? Yes, you all seem so welcoming... > And do notify developers how you expect interaction to be. Don't > expect developers (or anyone) to regularily poll the wiki page. In so far as the debugging process is documented on the wiki page, I *do* expect people (triagers and developers alike) to monitor the wiki pages that pertain to them for changes. It's a simple thing to do, requiring very little time. When a procedure is documented but not followed (or when a procedure is changed but the documentation isn't) is when problems like this entire thread arise. -- Wolfger http://wolfger.wordpress.com/ From henrik at ubuntu.com Mon May 26 21:05:40 2008 From: henrik at ubuntu.com (Henrik Nilsen Omma) Date: Mon, 26 May 2008 22:05:40 +0100 Subject: Proposed changes to workflow bug management In-Reply-To: <200805261545.36643.ubuntu@kitterman.com> References: <200805261545.36643.ubuntu@kitterman.com> Message-ID: <483B2624.50005@ubuntu.com> Scott Kitterman wrote: > At UDS Intrepid we had a good discussion between a few Ubuntu developers and > some people who are active in bugsquad (I recognize that many developers also > triage bugs. The discussion was focused on people who triage, but are not > developers.). I accepted the action to present the issue and proposed > solution to the development community for comment (I know bugsquad needs to > discuss this too, but I'm probably not the best one to lead that discussion). > > ... > > Please discuss. Thanks for writing this up Scott. One additional point: With a specific team subscribed to all these bugs (workflow-bug-team, say) it becomes easy to see them all together, either in the Launchpad listing of subscribed bugs for that team or in an external listing. Brian offered to prepare some suitable scripts to display listings of the different categories of workflow bugs in a public location. This could be updated every 5 minutes or whatever and such a script could also be taught to send useful updates to mailing lists. Examples of external bug listings: http://people.ubuntu.com/~ogasawara/hardy-buglist.html http://people.ubuntu.com/~ubuntu-archive/pending-sru.html As a result I think we can actually improve the tracking of these workflow bugs over what we have today, for developers as well as triagers. It is not the intention to hide these bugs from anyone who is interested but simply to avoid them turning up in default searches for users and triagers. If the hidden nature of these bugs is a problem we could have an open team as a sub-team of workflow-bug-team to facilitate that on an opt-in basis. Duplication should not be a problem because anyone likely to want to file such a bug would be an indirect member of workflow-bug-team and would see them in searches. We also considered setting up a separate workflow LP project to track these, but that was not favoured because it is useful to associate these tasks with Ubuntu packages. Setting all these bugs to Triaged or In Progress on filing has also been suggested, but has less support than the above proposal. Other constructive proposals are of course welcome :) Henrik From markluxton at ns.sympatico.ca Tue May 27 01:44:17 2008 From: markluxton at ns.sympatico.ca (Mark) Date: Mon, 26 May 2008 22:44:17 -0300 Subject: Firefox 3 b5 "Work Offline" Message-ID: <483B6771.8020106@ns.sympatico.ca> I just signed up to the bug squad so I hope it is ok to use this email addy to make a report. I am still using a dial up connection and so I tend to find bugs there. Still not that much support for dial up in most Linux's. Understandable but annoying. *Firefox 3 starts up in offline mode.* Tested on three PC's so far. I don't know yet if this is the case with NIC's. When I click a link in an email, Firefox starts up but fails to access the web address as it is in offline mode. When I start Firefox and type in an address, same problem. If I start a second instance of Firefox it starts up in Online mode as it should(with the first instance being online already). I realize this is a beta version of Firefox, so I am hoping this will get fixed. I have found other bugs but will make separate bug reports. Truly, Mark Luxton P.S. It sure would be nice to have a single launcher to connect and disconnect with one click...AND also start the firewall(Firestarter/Iptables). Gnome PPPon does not work well. It would be also reassuring if the launcher indicated being online and the firewall being active. openSUSE has a small tool that is close. -------------- next part -------------- An HTML attachment was scrubbed... URL: From siretart at ubuntu.com Tue May 27 05:55:45 2008 From: siretart at ubuntu.com (Reinhard Tartler) Date: Tue, 27 May 2008 07:55:45 +0200 Subject: Incomplete with no response >30 days References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> <20080525110549.70he2kvtvk4kscs@www.qense.nl> <874p8ldpu9.fsf@faui44a.informatik.uni-erlangen.de> <3b00b3330805261513y6495e472nf9bd8ac46a35d782@mail.gmail.com> Message-ID: <87bq2scmu6.fsf@faui44a.informatik.uni-erlangen.de> Wolfger writes: > On Mon, May 26, 2008 at 11:53 AM, Reinhard Tartler wrote: > >> So a pretty please with sugar on the top: If you don't understand what a >> bug is about, please do not touch it. This includes all what is recently >> called a "workflow bug". > > This is a pointless request, since it requires the person looking at > the bug to understand that he doesn't understand. People who think > they understand (but don't) are far more damaging than people who know > they don't understand. I fully agree with your rationale, but not why my request should be pointless. >> I'm a bit surprised that the bugsquad team focuses on triaging and >> editing bugs instead on generating statistics, showing trends and >> pointing to pointless bug statuses like bugs marked 'in progress' >> without assignee or bugs assigned to a team. > > I am totally confused by what you mean here. You are surprised that > bugsquad focuses on triaging bugs? In some ways. I've seen enough cases (and now I'm sorry I didn't make a list of such bugs) where triagers (at least I think they were triagers) made bugstatuses that confused me or the report or both. I'm e.g. still confused that everyone seems to be able to nominate bugs for release (but that's another story...) No really, triaging bugs is a real hard thing to do. I tried it out myself yesterday, and triaged about 8 bugs in the cryptsetup package. Some of them where rather old, some of them had even patches in them. It took me about 4 hours to triage these bugs. (this makes it nearly 30 minutes of thinking, testing and playing with each bug). That is because: - I really had to think what this bug is about. While in some cases I was short of setting up a virtual machine with gutsy or hardy to have a test setup, I most of the time I could get away without it. (most of the) - most of the patches don't apply directly. So I had to review them and try to apply them to the package. Them re-review the source package. You get the idea. Happened e.g. #95050 - some of them were just user requests, like #136760 - some of them were feature requests like #160083 or #126851, but it was not obvious that the package was lacking this functionality before looking at the source Granted, cryptsetup may be a challenging package. But from my experience with working with bugs in debian (and I do maintain a couple of packages there), I can tell that working on bugs is real hard work. And if you don't get it right in the first place, reporters will get pretty angry. For good reason, as I found out (btw. using the hard way). So yes, I am suprised why you guys decided to work on the hard tasks first instead of easier one to get experience. >> Developers don't need a group of people malicously editing their bugs, > > Ubuntu does not need people maliciously sowing dissent in the ranks of > the volunteers who work very hard to help Ubuntu. If you have evidence > that "a group of people" are "maliciously" editing bugs, then please > present that evidence so we can deal with these people. Leaving out the most important sentence of my mail is not going to help a productive conversation. >> And do notify developers how you expect interaction to be. Don't >> expect developers (or anyone) to regularily poll the wiki page. > > In so far as the debugging process is documented on the wiki page, I > *do* expect people (triagers and developers alike) to monitor the wiki > pages that pertain to them for changes. It's a simple thing to do, > requiring very little time. No, it is not. Please do not expect anyone to monitor a wiki for changes. If there are changes and developers need to be notified about something, you definitely need to post it to 'ubuntu-devel-announce at l.u.c', since that is the designated list for announcements. Developers are required to read it. The wiki changes are not. > When a procedure is documented but not followed (or when a procedure > is changed but the documentation isn't) is when problems like this > entire thread arise. I think this thread arose for a couple of reasons: - it was not propoerly communicated with the developers (and still is not. I don't consider this discussion as communication with the developers since it is on the wrong list, not every developer is required to read this. - Observations that people persumably members of the bugsquad have confused developers with changes to bugstatus - Big confusion on the developer side (at least it was for me) -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From siretart at ubuntu.com Tue May 27 07:29:30 2008 From: siretart at ubuntu.com (Reinhard Tartler) Date: Tue, 27 May 2008 09:29:30 +0200 Subject: Introduction to the ubuntu-bugsquad team Message-ID: <877idgcihx.fsf@faui44a.informatik.uni-erlangen.de> Dear bugsquad team, After having reread my recent contribution to this mailing list (like [6]), and considering the answers (and lack of answers, [4], to some extend [5] as well). I've come to the conclusion that my posts and their tone may not have been appropriate for this mailing list. I regret if they have been perceived as if I would imply that the bugsquad was not doing a great job when working on bugs, as implied by [1]. Contrary, we definitly need help on bugs. But I have concerns about what I have perceived while working on bugs in the past. In order to return to a more friendly atmosphere, I've decided to do a short introduction of myself to this mailing list. I'm Reinhard Tartler, joined to ubuntu around the hoary cycle, became Core-dev at UDS in Montreal (the UDS for the dapper cycle). My wiki page: * https://wiki.ubuntu.com/ReinhardTartler I have been interviewed by behindubuntu.com: * http://behindubuntu.org/interviews/ReinhardTartler/ My work on launchpad bugs so far: * https://bugs.launchpad.net/~siretart Packages I have touched in the past in ubuntu: * https://edge.launchpad.net/~siretart/+packages Nowadays I'm also a Debian Developers as well, where I care for bugs as well. The list of packages I (co-)maintain there can be seen here: * http://qa.debian.org/developer.php?login=siretart at tauware.de As you might now, there is nothing remotely similar to the bugsquad team in Debian. We do have a QA Team in debian, but that team mainly cares for so-called "orphaned" packages. Their work consists on working on bugs on that packages, but also on fixing bugs there. They are probably most comparable to the MOTU team in ubuntu. Since I switch a lot between these two communities, I found it increasingly difficult to follow changes to procedures and rules to follow. That's one of my biggest concern while working on ubuntu stuff in general: I think our documentation on workflow is way too instable and changes too often without proper announcements. And I really do consider watching a wiki for changes unacceptable to expect from developers. Especially for volunteer developers like me, but for canonical employees as well. While talking to various people at UDS in Prague, it seems that I'm not alone on this. There was a session about this at UDS, called policy-and-standards. I do hope that the bugsquad team will contribute to the Ubuntu Developers Reference as a way to indicate how developers can successfully interact with the bugsquad team. [2] In my opinion, there has been a lot of miscommunication in the past. Not only on this mailing list, but also on IRC and in malone. Heck, we are even miscommunicating when talking about miscommunication, as seen in e.g. in [1] and [3]. I'm going now a step back and will rethink the next days how this can be improved. Most preferably without not contributing at all to this mailing list. As a first step, I've signed up to this mailing list via mailman properly (I used to lurk here using gmane, but the email obfuscation is too annoying. Was that really necessary?), and wrote this introduction mail. I do hope I'll get some positive reposonse and that we find a way to work with each other. Thanks for your attention and please accept my apologies if my mails have been perceived as unproductive. Footnotes: [1] https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-May/000886.html [2] At that session the Ubuntu Developers Reference was discussed as an rewrite of the Debian Developers Reference for ubuntu. IIRC, Collin has volunteered to create a first draft, and I expect that he will announce the document when it is in a presentable state. Short: That document does not exist yet, but I think we desperately need it. [3] https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-May/000880.html [4] https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-May/000863.html [5] https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-May/000865.html [6] https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-May/000877.html -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From jw+debian at jameswestby.net Tue May 27 09:52:30 2008 From: jw+debian at jameswestby.net (James Westby) Date: Tue, 27 May 2008 10:52:30 +0100 Subject: Firefox 3 b5 "Work Offline" In-Reply-To: <483B6771.8020106@ns.sympatico.ca> References: <483B6771.8020106@ns.sympatico.ca> Message-ID: <1211881950.6483.35.camel@flash> On Mon, 2008-05-26 at 22:44 -0300, Mark wrote: > I just signed up to the bug squad so I hope it is ok to use this > email addy to make a report. Hi, This list isn't for the reporting of bugs, it is for the co-ordination of those who triage the bugs. Mailing the list will in all likely hood mean that your bug report is lost. Would you file a bug in launchpad at https://bugs.launchpad.net/ubuntu/+filebug please? That will ensure that your report will not be lost, and ensure that you are subscribed to it so that you can provide any needed information. If you have already done this then I apologise. Thanks, James From wolfger at gmail.com Tue May 27 10:01:13 2008 From: wolfger at gmail.com (Wolfger) Date: Tue, 27 May 2008 06:01:13 -0400 Subject: Incomplete with no response >30 days In-Reply-To: <87bq2scmu6.fsf@faui44a.informatik.uni-erlangen.de> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> <20080525110549.70he2kvtvk4kscs@www.qense.nl> <874p8ldpu9.fsf@faui44a.informatik.uni-erlangen.de> <3b00b3330805261513y6495e472nf9bd8ac46a35d782@mail.gmail.com> <87bq2scmu6.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <3b00b3330805270301v7c25520m8f42ecdb57491035@mail.gmail.com> On Tue, May 27, 2008 at 1:55 AM, Reinhard Tartler wrote: > Wolfger writes: > >> On Mon, May 26, 2008 at 11:53 AM, Reinhard Tartler wrote: >> >>> So a pretty please with sugar on the top: If you don't understand what a >>> bug is about, please do not touch it. This includes all what is recently >>> called a "workflow bug". >> >> This is a pointless request, since it requires the person looking at >> the bug to understand that he doesn't understand. People who think >> they understand (but don't) are far more damaging than people who know >> they don't understand. > > I fully agree with your rationale, but not why my request should be > pointless. The current case in point: This thread arose because I touched a workflow bug when I shouldn't have. In theory, your request would have stopped me (I didn't understand, so I shouldn't have touched it), but in reality your request does not stop me, because: a) I didn't know (and still really don't, aside from bdmurray's greasemonkey script) how to tell a workflow bug from a regular bug b) I didn't know (but now do) that the rules are different for workflow bugs than non-workflow bugs So your request does nothing to stop somebody from touching something they don't understand, if they think they understand it. Understand? >>> Developers don't need a group of people malicously editing their bugs, >> >> Ubuntu does not need people maliciously sowing dissent in the ranks of >> the volunteers who work very hard to help Ubuntu. If you have evidence >> that "a group of people" are "maliciously" editing bugs, then please >> present that evidence so we can deal with these people. > > Leaving out the most important sentence of my mail is not going to help > a productive conversation. Well, I went back and re-read that entire paragraph (all two sentences of it), and did not see anything mitigating the accusation that some nameless group is being malicious. Please help me out and tell me what the most important sentence is. >> When a procedure is documented but not followed (or when a procedure >> is changed but the documentation isn't) is when problems like this >> entire thread arise. > > I think this thread arose for a couple of reasons: > - it was not propoerly communicated with the developers (and still is > not. I don't consider this discussion as communication with the > developers since it is on the wrong list, not every developer is > required to read this. > - Observations that people persumably members of the bugsquad have > confused developers with changes to bugstatus > - Big confusion on the developer side (at least it was for me) Funny that you see this thread arose for 3 developer-centric reason, when the thread was started on a non-dev list by a non-dev. Perhaps these are reasons why the thread grew as large as it did, but (speaking as the person who started the thread) the thread arose because: 1) There was no easy way to tell one specific (and small) subcategory of bugs apart from the main 2) The subcategory has special rules and does not follow the "standard" rules for status. 3) The dev who owned the bug (but did not assign it to himself) got rather snippy with me when I touched it. Since then, I've encountered another subcategory of bugs that don't adhere to the standard rules (Mozilla), and the dev responding to me there was rather more helpful, and pointed me to a wiki entry for how to treat Mozilla bugs. Unfortunately I found issue there, too, since the bugs were not being handled in accordance with the Mozilla procedure, either. The procedure listed there was that an incomplete bug *must* have a tag indicating why it is incomplete, but the bugs I was touching were not so tagged. So really it all boils down to the need for better documentation of procedure, better adherence to procedure, and possibly a need for better procedures. We're all on the same team here, and I think some people (on both sides) are getting a little heated and forgetting this. -- Wolfger http://wolfger.wordpress.com/ From siretart at ubuntu.com Tue May 27 10:33:46 2008 From: siretart at ubuntu.com (Reinhard Tartler) Date: Tue, 27 May 2008 12:33:46 +0200 Subject: Proposed changes to workflow bug management In-Reply-To: <483BD772.8070703@ubuntu.com> (Henrik Nilsen Omma's message of "Tue, 27 May 2008 10:42:10 +0100") References: <200805261545.36643.ubuntu@kitterman.com> <8d41218e0805261656o78086a0bkb66c5d57ea48cc94@mail.gmail.com> <200805262209.54215.ubuntu@kitterman.com> <483BBD5A.4030107@ubuntu.com> <9bd2f8970805270124w5dcedc4bp406bae36bda4666d@mail.gmail.com> <87skw4az78.fsf@faui44a.informatik.uni-erlangen.de> <483BD772.8070703@ubuntu.com> Message-ID: <87k5hgaved.fsf@faui44a.informatik.uni-erlangen.de> CC'ing the bugsquad for more input on this idea. Henrik Nilsen Omma writes: > Reinhard Tartler wrote: >> I think we should ask the launchpad guys to prevent bugs to be >> assigned to a team. I know the kernel team is doing this, but I still >> haven't found out why. Could some member of the kernel team give a >> rationale for this please? >> > This is no longer current practice in the kernel team and the bugs > currently assigned to the team will be un-assigned. Bugs are now > assigned to individuals directly. So is my idea a basis on which consesus is reachable? If yes, I'm going to file a malone bug on malone for preventing teams to be assigned to a bug in ubuntu. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From jw+debian at jameswestby.net Tue May 27 10:37:28 2008 From: jw+debian at jameswestby.net (James Westby) Date: Tue, 27 May 2008 11:37:28 +0100 Subject: Proposed changes to workflow bug management In-Reply-To: <87k5hgaved.fsf@faui44a.informatik.uni-erlangen.de> References: <200805261545.36643.ubuntu@kitterman.com> <8d41218e0805261656o78086a0bkb66c5d57ea48cc94@mail.gmail.com> <200805262209.54215.ubuntu@kitterman.com> <483BBD5A.4030107@ubuntu.com> <9bd2f8970805270124w5dcedc4bp406bae36bda4666d@mail.gmail.com> <87skw4az78.fsf@faui44a.informatik.uni-erlangen.de> <483BD772.8070703@ubuntu.com> <87k5hgaved.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <1211884648.6483.49.camel@flash> On Tue, 2008-05-27 at 12:33 +0200, Reinhard Tartler wrote: > So is my idea a basis on which consesus is reachable? If yes, I'm going > to file a malone bug on malone for preventing teams to be assigned to a > bug in ubuntu. Do the desktop team not assign to a team as well? Thanks, James From siretart at ubuntu.com Tue May 27 14:18:36 2008 From: siretart at ubuntu.com (Reinhard Tartler) Date: Tue, 27 May 2008 16:18:36 +0200 Subject: Proposed changes to workflow bug management In-Reply-To: <1211891495.8844.71.camel@cunning> (Ben Collins's message of "Tue, 27 May 2008 08:31:35 -0400") References: <200805261545.36643.ubuntu@kitterman.com> <8d41218e0805261656o78086a0bkb66c5d57ea48cc94@mail.gmail.com> <200805262209.54215.ubuntu@kitterman.com> <483BBD5A.4030107@ubuntu.com> <9bd2f8970805270124w5dcedc4bp406bae36bda4666d@mail.gmail.com> <87skw4az78.fsf@faui44a.informatik.uni-erlangen.de> <483BD772.8070703@ubuntu.com> <87k5hgaved.fsf@faui44a.informatik.uni-erlangen.de> <1211891495.8844.71.camel@cunning> Message-ID: <87fxs3bzk3.fsf@faui44a.informatik.uni-erlangen.de> Ben Collins writes: > Take the intrepid linux-ports package that will be coming down the pipe. > The bugs will be split up on the basis of architecture. So assigning > bugs to the ubuntu-{powerpc,ia64,hppa,sparc} teams as a triage step > makes sense, and immediately shows responsibility. Then individuals in > those teams can take the bug. > > No one has yet explained a better way to handle this sort of workflow, Obvious way: don't assign, but subscribe the team that is going to handle the bug. The advantages: - it does not give users the false impression someone would actually work on that bug - several teams can be subscribed, which is not possible with assignments. Downsides: - subscriptions are not as exposed as assignments in the UI and perhaps a bit more difficult to use. And as Emmet points out in <9bd2f8970805270124w5dcedc4bp406bae36bda4666d at mail.gmail.com>, notification for assignees is very different to notification for subscribers. Seb128 pointed out on IRC that handling large amounts of bugs are supposed to be handeled easier than with subscriptions, but I have to admit that I don't really understand this argument. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From ben.collins at canonical.com Tue May 27 12:31:35 2008 From: ben.collins at canonical.com (Ben Collins) Date: Tue, 27 May 2008 08:31:35 -0400 Subject: Proposed changes to workflow bug management In-Reply-To: <87k5hgaved.fsf@faui44a.informatik.uni-erlangen.de> References: <200805261545.36643.ubuntu@kitterman.com> <8d41218e0805261656o78086a0bkb66c5d57ea48cc94@mail.gmail.com> <200805262209.54215.ubuntu@kitterman.com> <483BBD5A.4030107@ubuntu.com> <9bd2f8970805270124w5dcedc4bp406bae36bda4666d@mail.gmail.com> <87skw4az78.fsf@faui44a.informatik.uni-erlangen.de> <483BD772.8070703@ubuntu.com> <87k5hgaved.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <1211891495.8844.71.camel@cunning> On Tue, 2008-05-27 at 12:33 +0200, Reinhard Tartler wrote: > CC'ing the bugsquad for more input on this idea. > > Henrik Nilsen Omma writes: > > > Reinhard Tartler wrote: > >> I think we should ask the launchpad guys to prevent bugs to be > >> assigned to a team. I know the kernel team is doing this, but I still > >> haven't found out why. Could some member of the kernel team give a > >> rationale for this please? > >> > > This is no longer current practice in the kernel team and the bugs > > currently assigned to the team will be un-assigned. Bugs are now > > assigned to individuals directly. > > So is my idea a basis on which consesus is reachable? If yes, I'm going > to file a malone bug on malone for preventing teams to be assigned to a > bug in ubuntu. 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. Take the intrepid linux-ports package that will be coming down the pipe. The bugs will be split up on the basis of architecture. So assigning bugs to the ubuntu-{powerpc,ia64,hppa,sparc} teams as a triage step makes sense, and immediately shows responsibility. Then individuals in those teams can take the bug. No one has yet explained a better way to handle this sort of workflow, and until they do, I personally veto removing the ability to assign bugs to a team. From siretart at ubuntu.com Tue May 27 14:33:44 2008 From: siretart at ubuntu.com (Reinhard Tartler) Date: Tue, 27 May 2008 16:33:44 +0200 Subject: Incomplete with no response >30 days In-Reply-To: <87bq2scmu6.fsf@faui44a.informatik.uni-erlangen.de> (Reinhard Tartler's message of "Tue, 27 May 2008 07:55:45 +0200") References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <481EC0A7.2000104@ubuntu.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> <20080525110549.70he2kvtvk4kscs@www.qense.nl> <874p8ldpu9.fsf@faui44a.informatik.uni-erlangen.de> <3b00b3330805261513y6495e472nf9bd8ac46a35d782@mail.gmail.com> <87bq2scmu6.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <87abibbyuv.fsf@faui44a.informatik.uni-erlangen.de> Wolfger writes: > The current case in point: This thread arose because I touched a > workflow bug when I shouldn't have. In theory, your request would have > stopped me (I didn't understand, so I shouldn't have touched it), but > in reality your request does not stop me, because: > a) I didn't know (and still really don't, aside from bdmurray's > greasemonkey script) how to tell a workflow bug from a regular bug Waaait a minute. I now assume that you are talking about http://launchpad.net/bugs/154730? How much more clear can the title "Please remove secvpn source and binary from Hardy" with the team "Ubuntu Package Administrators" subscribed and a valid and understandable rationale in the bug description be? You definitly need to read the bug to understand it. > b) I didn't know (but now do) that the rules are different for > workflow bugs than non-workflow bugs Just by looking at that particular bug should have have given you the hint that this bug does not need any attention by the bugsquad team. It has been filed by an developer following the procedures given by the ubuntu package administrators with very clear instructions and rationale. And btw, the point of actually reading before acting is pretty valid for non-workflow bugs as well. If it wasn't, I'd we should change bugs like that fully automatically. However, this tends to cause a lot of fallout which we don't like. That's why we use humans to triage and do housekeeping on that bugs, because people usually do think before acting. [1] > So your request does nothing to stop somebody from touching something > they don't understand, if they think they understand it. Understand? I don't think this needs any more commenting. >> Leaving out the most important sentence of my mail is not going to help >> a productive conversation. > > Well, I went back and re-read that entire paragraph (all two sentences > of it), and did not see anything mitigating the accusation that some > nameless group is being malicious. Please help me out and tell me what > the most important sentence is. Let me see: Quoting from <874p8ldpu9.fsf at faui44a.informatik.uni-erlangen.de>: >> If there is a group of people randomly and cluelessly >> editing bugs, they must be stopped in order to enable developers to work >> effectivly. I don't have the impression that the bugsquad is such an >> group, at least not yet. However the arguments you rised in your mail >> could be interpreted this way. That's why this email is so harsh. > the thread arose because: > 1) There was no easy way to tell one specific (and small) subcategory > of bugs apart from the main I agree. However there is a straightforward way: Actually reading and understanding the bug you are touching. > 2) The subcategory has special rules and does not follow the > "standard" rules for status. > 3) The dev who owned the bug (but did not assign it to himself) got > rather snippy with me when I touched it. Which I acknoledge that it is a problem that should be fixed. I agree. Let's work together on that. Perhaps it makes sense to collect issues like that in malone? It is very hard to follow arguments on mailing lists like this. > So really it all boils down to the need for better documentation of > procedure, better adherence to procedure, and possibly a need for > better procedures. I'd like to add announcments and announcements of changes to those procedures to that list. [1] yes, we all do mistakes, including developers, and usually, that is not really a problem if the effects of the mistake can be fixed. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From hggdh2 at gmail.com Tue May 27 15:05:06 2008 From: hggdh2 at gmail.com (HggdH) Date: Tue, 27 May 2008 10:05:06 -0500 Subject: Introduction to the ubuntu-bugsquad team In-Reply-To: <877idgcihx.fsf@faui44a.informatik.uni-erlangen.de> References: <877idgcihx.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <1211900706.8993.80.camel@localhost> > Dear bugsquad team, > > After having reread my recent contribution to this mailing list (like > [6]), and considering the answers (and lack of answers, [4], to some > extend [5] as well). I've come to the conclusion that my posts and their > tone may not have been appropriate for this mailing list. I regret if > they have been perceived as if I would imply that the bugsquad was not > doing a great job when working on bugs, as implied by [1]. Contrary, we > definitly need help on bugs. But I have concerns about what I have > perceived while working on bugs in the past. > As a first step, I've signed up to this mailing list via mailman > properly (I used to lurk here using gmane, but the email obfuscation is > too annoying. Was that really necessary?), and wrote this introduction > mail. I do hope I'll get some positive reposonse and that we find a way > to work with each other. > > > Thanks for your attention and please accept my apologies if my mails > have been perceived as unproductive. Thank you Reinhard. Apologies accepted. Being one that -- also -- have written some probably miscontructed emails, I take this time to also apologise to all -- including you (and Hobbsee and ScottK also). There *is* misunderstanding from both sides, and I am starting to be afraid I have helped it :-(. Now that I know you are a DD, your original points are much clearer, and my response was certainly excessive. I again apologise. So not to confuse public apologies with work at hand, I will address your points on another email. THANK YOU! To my shame, you have done more than I have to help. ..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 brian at ubuntu.com Tue May 27 15:17:21 2008 From: brian at ubuntu.com (Brian Murray) Date: Tue, 27 May 2008 08:17:21 -0700 Subject: Bugs with status 'In Progress' without assignee In-Reply-To: <871w3rgb84.fsf@faui44a.informatik.uni-erlangen.de> References: <871w3rgb84.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <20080527151721.GF7382@murraytwins.com> On Sat, May 24, 2008 at 02:03:55PM +0200, Reinhard Tartler wrote: > > According to https://wiki.ubuntu.com/Bugs/Status, bugs with status 'In > Progress' "should" have an assignee. According to > http://tinyurl.com/5mvws2 there are currently about ~200 of such bugs. > > I clearly don't see the point in having such bugs. Could you please give > me a valid use case for this? It is possible the bugs predated the wiki page regarding bug status. > If there is none, I suggest to set all of them to triaged. I don't think they should all be set to to Triaged but rather that some investigation should be done into their current status. Some of the ones in that list appear quite old and may be fixed in Hardy if not earlier. -- 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 wolfger at gmail.com Tue May 27 16:00:50 2008 From: wolfger at gmail.com (Wolfger) Date: Tue, 27 May 2008 12:00:50 -0400 Subject: Introduction to the ubuntu-bugsquad team In-Reply-To: <877idgcihx.fsf@faui44a.informatik.uni-erlangen.de> References: <877idgcihx.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <3b00b3330805270900n711e1190jf1aa9e926b8be19@mail.gmail.com> On Tue, May 27, 2008 at 3:29 AM, Reinhard Tartler wrote: > > In order to return to a more friendly atmosphere, I've decided to do a > short introduction of myself to this mailing list. I'm Reinhard Tartler, > joined to ubuntu around the hoary cycle, became Core-dev at UDS in > Montreal (the UDS for the dapper cycle). Hello, Reinhard. Sorry we got off on the wrong foot! :-) I should probably introduce myself as well, since I'm not sure I ever did prior to the e-mail that ignited this all. I'm Mike Foster, though I go by Wolfger online (because Mike Foster is far too common a name, and I wouldn't want other people getting blamed for what I do). I've been using Kubuntu since Feisty (early in the Gutsy cycle), and decided shortly after the Gutsy release that I really wanted to start giving back to the community. Bug triage seemed to be an easy way to get started. I also wish to be a MotU some day, but that seems to be more time consuming, at least in the learning stages, and time is something I frequently find myself short of. I did a Bug Jam for the Michigan LoCo, and another one at Penguicon, trying to show people how easy (parts of) triage can be, and to encourage people to contribute in any way they can. I say that if you know how to navigate the web, and read a wiki, then you have the skill set necessary to help out! -- Wolfger http://wolfger.wordpress.com/ From wolfger at gmail.com Tue May 27 16:22:17 2008 From: wolfger at gmail.com (Wolfger) Date: Tue, 27 May 2008 12:22:17 -0400 Subject: Incomplete with no response >30 days In-Reply-To: <87abibbyuv.fsf@faui44a.informatik.uni-erlangen.de> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> <20080525110549.70he2kvtvk4kscs@www.qense.nl> <874p8ldpu9.fsf@faui44a.informatik.uni-erlangen.de> <3b00b3330805261513y6495e472nf9bd8ac46a35d782@mail.gmail.com> <87bq2scmu6.fsf@faui44a.informatik.uni-erlangen.de> <87abibbyuv.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <3b00b3330805270922hee57e26w81f1880f4ced9615@mail.gmail.com> On Tue, May 27, 2008 at 10:33 AM, Reinhard Tartler wrote: > > Wolfger writes: > >> a) I didn't know (and still really don't, aside from bdmurray's >> greasemonkey script) how to tell a workflow bug from a regular bug > > Waaait a minute. I now assume that you are talking about > http://launchpad.net/bugs/154730? How much more clear can the > title "Please remove secvpn source and binary from Hardy" with the > team "Ubuntu Package Administrators" subscribed and a valid and > understandable rationale in the bug description be? LOL. To me, it could be much clearer. I think the fact that it seems obvious to you and nearly invisible to me highlights the issue. 1) the title of the bug doesn't really say anything to me. Maybe that's a clue I should leave it alone, but I've seen (and successfully dealt with) many bugs which had titles that made no sense. I was going on the content... one single comment which went nearly half a year with no response or other indication that the bug was being worked on. 2) When I go to that link, I don't see who the subscribers are. That field is collapsed. I don't normally go looking at who is subscribed to a bug when I triage it. Even if the list of subscribers was visible, I never considered that to be pertinent information before. If it's unassigned, I tend to assume it's not being worked on. Obviously our perspectives are quite different, and I see now that I was in the wrong, but it astounds me that anybody thinks this is obvious. > Perhaps it makes sense to collect issues like that in malone? It is very > hard to follow arguments on mailing lists like this. I don't even know what "malone" is. Please educate me. >> So really it all boils down to the need for better documentation of >> procedure, better adherence to procedure, and possibly a need for >> better procedures. > > I'd like to add announcments and announcements of changes to those > procedures to that list. Sure. Communication is vital. Especially when it concerns new or changed procedures. -- Wolfger http://wolfger.wordpress.com/ My 5 today: #90080 (macchanger), #150557 (linux-source-2.6.20), #75818 (linux-source-2.6.15), #68329 (pbuilder), #185480 (octave3.0) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day From sense at qense.nl Tue May 27 16:41:23 2008 From: sense at qense.nl (sense at qense.nl) Date: Tue, 27 May 2008 18:41:23 +0200 Subject: Incomplete with no response >30 days In-Reply-To: <3b00b3330805270922hee57e26w81f1880f4ced9615@mail.gmail.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> <20080525110549.70he2kvtvk4kscs@www.qense.nl> <874p8ldpu9.fsf@faui44a.informatik.uni-erlangen.de> <3b00b3330805261513y6495e472nf9bd8ac46a35d782@mail.gmail.com> <87bq2scmu6.fsf@faui44a.informatik.uni-erlangen.de> <87abibbyuv.fsf@faui44a.informatik.uni-erlangen.de> <3b00b3330805270922hee57e26w81f1880f4ced9615@mail.gmail.com> Message-ID: <20080527184123.retayedauc0kccso@www.qense.nl> Quoting Wolfger : > On Tue, May 27, 2008 at 10:33 AM, Reinhard Tartler > wrote: >> >> Wolfger writes: >> >>> a) I didn't know (and still really don't, aside from bdmurray's >>> greasemonkey script) how to tell a workflow bug from a regular bug >> >> Waaait a minute. I now assume that you are talking about >> http://launchpad.net/bugs/154730? How much more clear can the >> title "Please remove secvpn source and binary from Hardy" with the >> team "Ubuntu Package Administrators" subscribed and a valid and >> understandable rationale in the bug description be? > > LOL. To me, it could be much clearer. I think the fact that it seems > obvious to you and nearly invisible to me highlights the issue. > 1) the title of the bug doesn't really say anything to me. Maybe > that's a clue I should leave it alone, but I've seen (and successfully > dealt with) many bugs which had titles that made no sense. I was going > on the content... one single comment which went nearly half a year > with no response or other indication that the bug was being worked on. > 2) When I go to that link, I don't see who the subscribers are. That > field is collapsed. I don't normally go looking at who is subscribed > to a bug when I triage it. Even if the list of subscribers was > visible, I never considered that to be pertinent information before. > If it's unassigned, I tend to assume it's not being worked on. > Obviously our perspectives are quite different, and I see now that I > was in the wrong, but it astounds me that anybody thinks this is > obvious. > >> Perhaps it makes sense to collect issues like that in malone? It is very >> hard to follow arguments on mailing lists like this. > > I don't even know what "malone" is. Please educate me. > >>> So really it all boils down to the need for better documentation of >>> procedure, better adherence to procedure, and possibly a need for >>> better procedures. >> >> I'd like to add announcments and announcements of changes to those >> procedures to that list. > > Sure. Communication is vital. Especially when it concerns new or > changed procedures. > > > -- > Wolfger > http://wolfger.wordpress.com/ > > My 5 today: #90080 (macchanger), #150557 (linux-source-2.6.20), #75818 > (linux-source-2.6.15), #68329 (pbuilder), #185480 (octave3.0) > Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > That's what we were trying to say all the time! But I felt that a lot of developers didn't want to listen somehow. If you just say in capitals at the beginning of each workflow report: "WORKFLOW BUG" I think we won't touch it. Maybe you should add the the bugsuad shouldn't touch it, I don't know. But it's much easier that hiding certain bugs, which makes the project less transparant and thus harder to understand for newcomers. We proposed something simple like this several times, but it seemed like no one did do anything with it. What do you have against this idea? Why is it so bad? Isn't it that simple things are often the best solutions? Sense PS: Malone is the bug tracker in Launchpad. From caroline.ford.work at googlemail.com Tue May 27 17:30:57 2008 From: caroline.ford.work at googlemail.com (Caroline Ford) Date: Tue, 27 May 2008 18:30:57 +0100 Subject: Introduction to the ubuntu-bugsquad team In-Reply-To: <877idgcihx.fsf@faui44a.informatik.uni-erlangen.de> References: <877idgcihx.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: 2008/5/27 Reinhard Tartler : > > Dear bugsquad team, > > After having reread my recent contribution to this mailing list (like > [6]), and considering the answers (and lack of answers, [4], to some > extend [5] as well). I've come to the conclusion that my posts and their > tone may not have been appropriate for this mailing list. I regret if > they have been perceived as if I would imply that the bugsquad was not > doing a great job when working on bugs, as implied by [1]. Contrary, we > definitly need help on bugs. But I have concerns about what I have > perceived while working on bugs in the past. > Thank you for your apology :) > In order to return to a more friendly atmosphere, I've decided to do a > short introduction of myself to this mailing list. I'm Reinhard Tartler, > joined to ubuntu around the hoary cycle, became Core-dev at UDS in > Montreal (the UDS for the dapper cycle). I'm Caroline Ford, I've been doing bug triage since Dapper. I'm also a developer of tuxpaint (creating free content) and an administrator of Wikipedia. Caroline From caroline.ford.work at googlemail.com Tue May 27 17:48:07 2008 From: caroline.ford.work at googlemail.com (Caroline Ford) Date: Tue, 27 May 2008 18:48:07 +0100 Subject: Incomplete with no response >30 days In-Reply-To: <20080527184123.retayedauc0kccso@www.qense.nl> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> <20080525110549.70he2kvtvk4kscs@www.qense.nl> <874p8ldpu9.fsf@faui44a.informatik.uni-erlangen.de> <3b00b3330805261513y6495e472nf9bd8ac46a35d782@mail.gmail.com> <87bq2scmu6.fsf@faui44a.informatik.uni-erlangen.de> <87abibbyuv.fsf@faui44a.informatik.uni-erlangen.de> <3b00b3330805270922hee57e26w81f1880f4ced9615@mail.gmail.com> <20080527184123.retayedauc0kccso@www.qense.nl> Message-ID: 2008/5/27 : > PS: Malone is the bug tracker in Launchpad. I think it's the old name, although there are still references to it. I think it was rebranded as Launchpad Bugs, in the same way that rosetta is Launchpad Translations. If you file a bug against the launchpad components you still file it against malone and rosetta though. Caroline From ben.collins at canonical.com Tue May 27 17:27:38 2008 From: ben.collins at canonical.com (Ben Collins) Date: Tue, 27 May 2008 13:27:38 -0400 Subject: Proposed changes to workflow bug management In-Reply-To: <87fxs3bzk3.fsf@faui44a.informatik.uni-erlangen.de> References: <200805261545.36643.ubuntu@kitterman.com> <8d41218e0805261656o78086a0bkb66c5d57ea48cc94@mail.gmail.com> <200805262209.54215.ubuntu@kitterman.com> <483BBD5A.4030107@ubuntu.com> <9bd2f8970805270124w5dcedc4bp406bae36bda4666d@mail.gmail.com> <87skw4az78.fsf@faui44a.informatik.uni-erlangen.de> <483BD772.8070703@ubuntu.com> <87k5hgaved.fsf@faui44a.informatik.uni-erlangen.de> <1211891495.8844.71.camel@cunning> <87fxs3bzk3.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <1211909258.7648.25.camel@cunning> On Tue, 2008-05-27 at 16:18 +0200, Reinhard Tartler wrote: > Ben Collins writes: > > > Take the intrepid linux-ports package that will be coming down the pipe. > > The bugs will be split up on the basis of architecture. So assigning > > bugs to the ubuntu-{powerpc,ia64,hppa,sparc} teams as a triage step > > makes sense, and immediately shows responsibility. Then individuals in > > those teams can take the bug. > > > > No one has yet explained a better way to handle this sort of workflow, > > Obvious way: don't assign, but subscribe the team that is going to > handle the bug. > > The advantages: > - it does not give users the false impression someone would actually > work on that bug I don't see how users get that impression. In-Progress is what is meant to show that a bug is being worked on. Assignment just shows who is ultimately responsible for the next stage of the workflow. Once it is triaged, in the case I outlined, then a team is responsible for the next step (not a single person). That next step is deciding whether it should be fixed or not, and then having a person work on it. I also disagree that assigning to a team means that no one feels responsible for it. In fact, the alternative for the above situation is to assign to no one, which means no one need even bother look at it. The workflow I suggest, assigning to a team, leaves the team feeling responsible, and is a good way for new persons in the team to get their hands dirty (look for bugs assigned to the team). > - several teams can be subscribed, which is not possible with > assignments. Subscriptions to me are more of a list-of-interested parties. In no way do they describe or show responsibility. > Downsides: > > - subscriptions are not as exposed as assignments in the UI and perhaps > a bit more difficult to use. And this is ultimately what makes sub's vs. assignee useless for this type of work flow. New volunteers to a team will need things to be more visible to them than seasoned bug workers and developers. My method caters to these new people (which are extremely important for bug triaging), while the alternative caters to people in-the-know, just so we can get rid of a feature that has been successfully used going on two years now. All of the suggestions so far are just replacing a well known abuse with a lesser known abuse. Let's replace it with functionality that is suited to the problem instead, before getting rid of it. Another alternative, at least for my concern, is to be able to target bugs to a specific architecture or architectures. This way, one can easily perform search for the architecture they are interested in, regardless of the assignee. But I suspect launchpad developers expect people to use tags for that (which for me are useless, because they are arbitrary and we have no way to discourage things like "ppc" vs. "powerpc"). From caroline.ford.work at googlemail.com Tue May 27 18:44:29 2008 From: caroline.ford.work at googlemail.com (Caroline Ford) Date: Tue, 27 May 2008 19:44:29 +0100 Subject: Proposed changes to workflow bug management In-Reply-To: <1211909258.7648.25.camel@cunning> References: <200805261545.36643.ubuntu@kitterman.com> <200805262209.54215.ubuntu@kitterman.com> <483BBD5A.4030107@ubuntu.com> <9bd2f8970805270124w5dcedc4bp406bae36bda4666d@mail.gmail.com> <87skw4az78.fsf@faui44a.informatik.uni-erlangen.de> <483BD772.8070703@ubuntu.com> <87k5hgaved.fsf@faui44a.informatik.uni-erlangen.de> <1211891495.8844.71.camel@cunning> <87fxs3bzk3.fsf@faui44a.informatik.uni-erlangen.de> <1211909258.7648.25.camel@cunning> Message-ID: 2008/5/27 Ben Collins : > Another alternative, at least for my concern, is to be able to target > bugs to a specific architecture or architectures. This way, one can > easily perform search for the architecture they are interested in, > regardless of the assignee. But I suspect launchpad developers expect > people to use tags for that (which for me are useless, because they are > arbitrary and we have no way to discourage things like "ppc" vs. > "powerpc"). Launchpad tags are useless - just a long list of noise, most with 0s afterwards. Caroline From henrik at canonical.com Tue May 27 19:01:02 2008 From: henrik at canonical.com (Henrik Nilsen Omma) Date: Tue, 27 May 2008 20:01:02 +0100 Subject: Incomplete with no response >30 days In-Reply-To: <20080527184123.retayedauc0kccso@www.qense.nl> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <48219F3C.8090508@canonical.com> <1211641509.6483.2.camel@flash> <1211647727.6661.5.camel@localhost> <48392462.9080106@ubuntu.com> <20080525110549.70he2kvtvk4kscs@www.qense.nl> <874p8ldpu9.fsf@faui44a.informatik.uni-erlangen.de> <3b00b3330805261513y6495e472nf9bd8ac46a35d782@mail.gmail.com> <87bq2scmu6.fsf@faui44a.informatik.uni-erlangen.de> <87abibbyuv.fsf@faui44a.informatik.uni-erlangen.de> <3b00b3330805270922hee57e26w81f1880f4ced9615@mail.gmail.com> <20080527184123.retayedauc0kccso@www.qense.nl> Message-ID: <483C5A6E.70806@canonical.com> sense at qense.nl wrote: > If you just say in > capitals at the beginning of each workflow report: "WORKFLOW BUG" I > think we won't touch it. Simple, but probably effective. It may prove to be the best option as we are having difficulty getting consensus on using privacy, states or assignment. If each wokflow bug started with a standard text blob pasted from a wiki page they could be self-explanatory. That should take a few seconds to copy and paste and could even be added later if it was left out. It could link to a wiki page with a longer explanation. These bugs would continue to appear in default searches and so it would continue to crop up on working lists of triage teams. OTOH many such lists are generated with bughelper (like the bugday lists), which can easily be taught to leave out these bugs. Henrik From mantha at ubuntu.com Tue May 27 19:38:41 2008 From: mantha at ubuntu.com (Jordan Mantha) Date: Tue, 27 May 2008 12:38:41 -0700 Subject: Incomplete with no response >30 days In-Reply-To: <483C5A6E.70806@canonical.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <48392462.9080106@ubuntu.com> <20080525110549.70he2kvtvk4kscs@www.qense.nl> <874p8ldpu9.fsf@faui44a.informatik.uni-erlangen.de> <3b00b3330805261513y6495e472nf9bd8ac46a35d782@mail.gmail.com> <87bq2scmu6.fsf@faui44a.informatik.uni-erlangen.de> <87abibbyuv.fsf@faui44a.informatik.uni-erlangen.de> <3b00b3330805270922hee57e26w81f1880f4ced9615@mail.gmail.com> <20080527184123.retayedauc0kccso@www.qense.nl> <483C5A6E.70806@canonical.com> Message-ID: <8d41218e0805271238n51420f55n87b5b375c140ab76@mail.gmail.com> On Tue, May 27, 2008 at 12:01 PM, Henrik Nilsen Omma wrote: > sense at qense.nl wrote: > > If you just say in > > capitals at the beginning of each workflow report: "WORKFLOW BUG" I > > think we won't touch it. > Simple, but probably effective. It may prove to be the best option as we > are having difficulty getting consensus on using privacy, states or > assignment. > > If each wokflow bug started with a standard text blob pasted from a wiki > page they could be self-explanatory. That should take a few seconds to > copy and paste and could even be added later if it was left out. It > could link to a wiki page with a longer explanation. > > These bugs would continue to appear in default searches and so it would > continue to crop up on working lists of triage teams. OTOH many such > lists are generated with bughelper (like the bugday lists), which can > easily be taught to leave out these bugs. While I do think this could be a good "solution", why not just educate people on what kinds of bugs are out there? I have great confidence in the learning abilities of Ubuntu contributors and I think it's often better to educate rather than ignore/hide/obfuscate. From what I've seen almost all cases where we've had problems is when people didn't know any better. That sounds like an education and community integration problem to me. Triaging is a part of the Ubuntu development process and as such triagers and packagers should be working together in a common space and with common goals. Triaging is a subset of development activities and so triagers should be within that community and should feel like they are. I believe it was only when triaging was split off into it's own entity because of scaling issues and the two communities (triagers and packagers) grew apart that we ran into problems. Can we perhaps work to bring them back together more? If I were a budding triager (as I was once upon a time) I would want to know about *all* kinds of bugs and how they're used and to talk with packagers about how they do what they do. Would something like a mentoring program be feasible? Perhaps triagers who have similar working hours to a developer/packager/advanced triagers can work with them on the education process. Perhaps also weekly Triager Education classes could be done to go over issues like workflow bugs. I don't expect things like workflow bugs to be obvious to new triagers, but I *do* expect them to have a willingness to learn because that is at the heart of our community. -Jordan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hggdh2 at gmail.com Tue May 27 21:05:50 2008 From: hggdh2 at gmail.com (HggdH) Date: Tue, 27 May 2008 16:05:50 -0500 Subject: Incomplete with no response >30 days In-Reply-To: <8d41218e0805271238n51420f55n87b5b375c140ab76@mail.gmail.com> References: <3b00b3330805041008x6abdb26en594087b16a2ca226@mail.gmail.com> <48392462.9080106@ubuntu.com> <20080525110549.70he2kvtvk4kscs@www.qense.nl> <874p8ldpu9.fsf@faui44a.informatik.uni-erlangen.de> <3b00b3330805261513y6495e472nf9bd8ac46a35d782@mail.gmail.com> <87bq2scmu6.fsf@faui44a.informatik.uni-erlangen.de> <87abibbyuv.fsf@faui44a.informatik.uni-erlangen.de> <3b00b3330805270922hee57e26w81f1880f4ced9615@mail.gmail.com> <20080527184123.retayedauc0kccso@www.qense.nl> <483C5A6E.70806@canonical.com> <8d41218e0805271238n51420f55n87b5b375c140ab76@mail.gmail.com> Message-ID: <1211922350.12829.58.camel@localhost> On Tue, 2008-05-27 at 12:38 -0700, Jordan Mantha wrote: > While I do think this could be a good "solution", why not just educate > people on what kinds of bugs are out there? Both of them should be pursued. Clear identification -- even redundant -- is always better. At the same time errors should be pointed out and corrected with good manners. But, on the other hand, there are bugs, and there are things that look like bugs, smell like bugs, and feel to the touch like bugs, but are not bugs. Duh. The fact is we are overloading the BTS with tasks, we are using the BTS a bit outside its original scope. As such, both education and clear markings could be used. This is not the best possible scenario, but is one that would allow us to keep on until LP development catches up. > I have great confidence in the learning abilities of Ubuntu > contributors and I think it's often better to educate rather than > ignore/hide/obfuscate. From what I've seen almost all cases where > we've had problems is when people didn't know any better. That sounds > like an education and community integration problem to me. Triaging is > a part of the Ubuntu development process and as such triagers and > packagers should be working together in a common space and with common > goals. Triaging is a subset of development activities and so triagers > should be within that community and should feel like they are. Good point. We can also add in the fact that some packages would benefit from specialised trial requirements. The bugsquad has some requirements written [1], but it is rather incomplete. Developers/maintainers with specific requirements could help writing their "ideal" bug data; the bugsquad can help in normalising all contributions, and putting them available on the wiki. Reinhard Tartler, for example, has just done so (see [2]), and we are trying to contact him to get it published (TZ issues caused me to fail on that today). And, to stress Jordan's point -- education helps a lot. Always. Even when some say users cannot be educated (and I myself have said that, in despair, when trying to explain some requirements or clear up some misconceptions -- not amazingly, mostly related to security). > I believe it was only when triaging was split off into it's own entity > because of scaling issues and the two communities (triagers and > packagers) grew apart that we ran into problems. I was not playing with Ubuntu when this split happened but, having worked on some software houses, this does not surprise me. Yes, they will grow apart: they deal with different issues. Nevertheless, triaging is an ideal exposure for future developers, if a triager wants to go in this direction. But we should not allow triagers and packagers/developers/maintainers to grow so much apart as it seems to be the case nowadays. We need, we desperately need, to maintain a dialog. We also depend on the contributors from all sides. Ergo, dialog is required. Respect for both sides is required. > Can we perhaps work to bring them back together more? If I were a > budding triager (as I was once upon a time) I would want to know about > *all* kinds of bugs and how they're used and to talk with packagers > about how they do what they do. Would something like a mentoring > program be feasible? Perhaps triagers who have similar working hours > to a developer/packager/advanced triagers can work with them on the > education process. Perhaps also weekly Triager Education classes could > be done to go over issues like workflow bugs. I don't expect things > like workflow bugs to be obvious to new triagers, but I *do* expect > them to have a willingness to learn because that is at the heart of > our community. It is clear, methinks, that more education classes on (for example) #ubuntu-classroom) are needed. Another good point. Everybody must be willing to learn. Triagers must learn about specific packages requirements, and packagers must learn (or remember) what it is to do support on high volume. And, as far as I can understand, this all has to be documented, and the procedures should as much as possible *not* create exceptions (or, at least, not create too many of them). ..hggdh.. [1] https://wiki.ubuntu.com/DebuggingProcedures I note that the material there was written by contributors from all areas. [2] https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-May/000863.html -------------- 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 henrik at ubuntu.com Tue May 27 22:45:48 2008 From: henrik at ubuntu.com (Henrik Nilsen Omma) Date: Tue, 27 May 2008 23:45:48 +0100 Subject: Proposed changes to workflow bug management In-Reply-To: <72409-SnapperMsgD8DB99B6C4623D3C@[70.208.53.190]> References: <200805261545.36643.ubuntu@kitterman.com> <20080526204057.GA11813@vorlon.ping.de> <200805261648.08174.ubuntu@kitterman.com> <72409-SnapperMsgD8DB99B6C4623D3C@[70.208.53.190]> Message-ID: <483C8F1C.9090602@ubuntu.com> Scott Kitterman wrote: >> Why not just use a "workflow" tag? That is quite unambiguous, easy to >> spot and easy to implement here and now. As an experiment, I tried >> defining this on a few of "my" workflow bugs, and to my amazement, it >> was non-existent. >> >> > Maybe. So far I find tags very hard to work with. It would still need training for bugsquad > people to know to avoid it. > > So far I like "Maybe people shouldn't touch bugs they don't understand" the best. > I've started a wiki wiki page to help us track the current suggestions: https://wiki.ubuntu.com/WorkflowBugsDiscussion It's clearly not complete, esp. the Pros and Cons. Please help me fill it in. On that page the ideas mentioned here (tags and don't-touch) are proposals #5 and #1 respectively. Henrik From mrooney at gmail.com Tue May 27 23:33:17 2008 From: mrooney at gmail.com (Mike Rooney) Date: Tue, 27 May 2008 19:33:17 -0400 Subject: Proposed changes to workflow bug management In-Reply-To: <1211909258.7648.25.camel@cunning> References: <200805261545.36643.ubuntu@kitterman.com> <200805262209.54215.ubuntu@kitterman.com> <483BBD5A.4030107@ubuntu.com> <9bd2f8970805270124w5dcedc4bp406bae36bda4666d@mail.gmail.com> <87skw4az78.fsf@faui44a.informatik.uni-erlangen.de> <483BD772.8070703@ubuntu.com> <87k5hgaved.fsf@faui44a.informatik.uni-erlangen.de> <1211891495.8844.71.camel@cunning> <87fxs3bzk3.fsf@faui44a.informatik.uni-erlangen.de> <1211909258.7648.25.camel@cunning> Message-ID: <4f4806ee0805271633g47300e2at17e38ed7ec23fa63@mail.gmail.com> On Tue, May 27, 2008 at 1:27 PM, Ben Collins wrote: > On Tue, 2008-05-27 at 16:18 +0200, Reinhard Tartler wrote: >> Ben Collins writes: >> >> > Take the intrepid linux-ports package that will be coming down the pipe. >> > The bugs will be split up on the basis of architecture. So assigning >> > bugs to the ubuntu-{powerpc,ia64,hppa,sparc} teams as a triage step >> > makes sense, and immediately shows responsibility. Then individuals in >> > those teams can take the bug. >> > >> > No one has yet explained a better way to handle this sort of workflow, >> >> Obvious way: don't assign, but subscribe the team that is going to >> handle the bug. >> >> The advantages: >> - it does not give users the false impression someone would actually >> work on that bug > > I don't see how users get that impression. In-Progress is what is meant > to show that a bug is being worked on. Assignment just shows who is > ultimately responsible for the next stage of the workflow. Once it is > triaged, in the case I outlined, then a team is responsible for the next > step (not a single person). That next step is deciding whether it should > be fixed or not, and then having a person work on it. > This makes perfect sense to me. If a bug isn't "In Progress", I shouldn't assume it is in progress (ie being worked on actively by that team)! This way assigning to teams doesn't lose any information, and I do agree bugs should be assignable to teams. By the way, I am Mike Rooney (https://wiki.ubuntu.com/MikeRooney). - Mike From mantha at ubuntu.com Wed May 28 00:22:46 2008 From: mantha at ubuntu.com (Jordan Mantha) Date: Tue, 27 May 2008 17:22:46 -0700 Subject: Proposed changes to workflow bug management In-Reply-To: <4f4806ee0805271633g47300e2at17e38ed7ec23fa63@mail.gmail.com> References: <200805261545.36643.ubuntu@kitterman.com> <483BBD5A.4030107@ubuntu.com> <9bd2f8970805270124w5dcedc4bp406bae36bda4666d@mail.gmail.com> <87skw4az78.fsf@faui44a.informatik.uni-erlangen.de> <483BD772.8070703@ubuntu.com> <87k5hgaved.fsf@faui44a.informatik.uni-erlangen.de> <1211891495.8844.71.camel@cunning> <87fxs3bzk3.fsf@faui44a.informatik.uni-erlangen.de> <1211909258.7648.25.camel@cunning> <4f4806ee0805271633g47300e2at17e38ed7ec23fa63@mail.gmail.com> Message-ID: <8d41218e0805271722x6845f1efv8c043c33c92580@mail.gmail.com> On Tue, May 27, 2008 at 4:33 PM, Mike Rooney wrote: > On Tue, May 27, 2008 at 1:27 PM, Ben Collins > wrote: > > On Tue, 2008-05-27 at 16:18 +0200, Reinhard Tartler wrote: > >> Ben Collins writes: > >> > >> > Take the intrepid linux-ports package that will be coming down the > pipe. > >> > The bugs will be split up on the basis of architecture. So assigning > >> > bugs to the ubuntu-{powerpc,ia64,hppa,sparc} teams as a triage step > >> > makes sense, and immediately shows responsibility. Then individuals in > >> > those teams can take the bug. > >> > > >> > No one has yet explained a better way to handle this sort of workflow, > >> > >> Obvious way: don't assign, but subscribe the team that is going to > >> handle the bug. > >> > >> The advantages: > >> - it does not give users the false impression someone would actually > >> work on that bug > > > > I don't see how users get that impression. In-Progress is what is meant > > to show that a bug is being worked on. Assignment just shows who is > > ultimately responsible for the next stage of the workflow. Once it is > > triaged, in the case I outlined, then a team is responsible for the next > > step (not a single person). That next step is deciding whether it should > > be fixed or not, and then having a person work on it. > > > > This makes perfect sense to me. If a bug isn't "In Progress", I > shouldn't assume it is in progress (ie being worked on actively by > that team)! This way assigning to teams doesn't lose any information, > and I do agree bugs should be assignable to teams. That depends on what you mean by "actively being worked on". I would consider triage and many other statuses besides "In Progress" as being "work". The impression I get is that indeed people view assignment as "somebody's actively working on this". So if you assign a team that's not more likely to work on the bug than if they weren't assigned, I can see the false impression Reinhard talked about. For instance, assigning the MOTU team to all Universe bugs is pointless and in fact quite irritating and counterproductive. -Jordan -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.holbach at ubuntu.com Wed May 28 06:48:43 2008 From: daniel.holbach at ubuntu.com (Daniel Holbach) Date: Wed, 28 May 2008 08:48:43 +0200 Subject: Patch Statuses in Launchpad (re-visited) In-Reply-To: <483AC2D9.40701@ubuntu.com> References: <483AC2D9.40701@ubuntu.com> Message-ID: <483D004B.50101@ubuntu.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everybody, I thought about my initial proposal again and must say I wasn't too happy with the use of tags either, I still think though that it's vitally important to not lose bugs that have proposed solutions in the mediocrity of the huge list of bugs (all bugs marked as medium, all bugs marked as new). I'd like to make use of three list in my new proposal: https://launchpad.net/ubuntu/+bugs?field.has_patch=on would be the general lists of bugs with patches. Daniel Holbach schrieb: > - use "patch-needs-work" if you reviewed a patch and it needs more work > (or you flat-out rejected it) Can we agree on using "Incomplete" in this case? https://launchpad.net/ubuntu/+bugs?field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.has_patch=on then would be the list of bugs with patches that still need work. > - use "patch-went-upstream" if you forwarded it upstream to get their > input before uploading it to Ubuntu If we add an upstream task, we could make use of https://launchpad.net/ubuntu/+bugs?field.status_upstream=open_upstream&field.has_patch=on that are forwarded upstream and still need upstream input and https://launchpad.net/ubuntu/+bugs?field.status_upstream=resolved_upstream&field.has_patch=on the patches that were forwarded upstream and the upstream bugs that have been resolved. I repeat: untagging the "patch flag" is easier, but we lose information that is very important if we don't want to lose possible solutions in the 40k bugs we have open anyway. Let me know what you think. Have a nice day, Daniel - -- My 5 today: #234288 (grub2), #234992 (apturl), #235373 (mtools), #229864 (ttf-unfonts), #234457 (ygraph) 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 iD8DBQFIPQBKRjrlnQWd1esRAlECAJ4hYmLO4LCYVXUgueH2QQsz5A8riwCfcLvh /cKUhAJ8cMuqpM6KURTO+ng= =sswO -----END PGP SIGNATURE----- From siretart at ubuntu.com Wed May 28 07:03:01 2008 From: siretart at ubuntu.com (Reinhard Tartler) Date: Wed, 28 May 2008 09:03:01 +0200 Subject: Patch Statuses in Launchpad (re-visited) In-Reply-To: <483D004B.50101@ubuntu.com> (Daniel Holbach's message of "Wed, 28 May 2008 08:48:43 +0200") References: <483AC2D9.40701@ubuntu.com> <483D004B.50101@ubuntu.com> Message-ID: <87k5he6hcq.fsf@faui44a.informatik.uni-erlangen.de> Daniel Holbach writes: > Daniel Holbach schrieb: >> - use "patch-needs-work" if you reviewed a patch and it needs more work >> (or you flat-out rejected it) > > Can we agree on using "Incomplete" in this case? > https://launchpad.net/ubuntu/+bugs?field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.has_patch=on > then would be the list of bugs with patches that still need work. That would confuse the original reporter if it wasn't him who submitted the patch. I would consider this a pretty common case. Moreover we need to make sure that such bugs have the assignee field set properly because of two reasons: - bugs set to "Incomplete" are subject to expiration - we need to make clear who needs to act next on the bug. In that case we want the patch submitter to work on the patch, not the reporter. At UDS kiko told me that the incomplete status could be translated to "the developer asks the submitter to provide additional information". That's one reason why expiration was introduced in the first place. >> - use "patch-went-upstream" if you forwarded it upstream to get their >> input before uploading it to Ubuntu > > If we add an upstream task, we could make use of > https://launchpad.net/ubuntu/+bugs?field.status_upstream=open_upstream&field.has_patch=on > that are forwarded upstream and still need upstream input and > https://launchpad.net/ubuntu/+bugs?field.status_upstream=resolved_upstream&field.has_patch=on > the patches that were forwarded upstream and the upstream bugs that have > been resolved. This does only work if: - upstream uses a bugtracker at all - the bugtracker is supported by launchpad - the bugtracker registered with launchpad properly I'd be interested to know how many bugs with patches are affected by these problems though. > I repeat: untagging the "patch flag" is easier, but we lose information > that is very important if we don't want to lose possible solutions in > the 40k bugs we have open anyway. > > Let me know what you think. I think we need to investigate these 40k bugs in more detail. I hope we can classify them more, so it become easier to batch process them. I furthermore think this is a discussion that should definitly happen within the ubuntu developer community, and not solely on the bugsquad list. (the last paragraph is just my personal opinion since you have asked for it) -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From siretart at ubuntu.com Wed May 28 07:05:05 2008 From: siretart at ubuntu.com (Reinhard Tartler) Date: Wed, 28 May 2008 09:05:05 +0200 Subject: Bugs with status 'In Progress' without assignee In-Reply-To: <20080527151721.GF7382@murraytwins.com> (Brian Murray's message of "Tue, 27 May 2008 08:17:21 -0700") References: <871w3rgb84.fsf@faui44a.informatik.uni-erlangen.de> <20080527151721.GF7382@murraytwins.com> Message-ID: <87fxs26h9a.fsf@faui44a.informatik.uni-erlangen.de> Brian Murray writes: >> If there is none, I suggest to set all of them to triaged. > > I don't think they should all be set to to Triaged but rather that some > investigation should be done into their current status. Some of the > ones in that list appear quite old and may be fixed in Hardy if not > earlier. Exactly. I should have been more clear here. Is this something we can ask the bugsquad team to do? I mean going through the list of bugs with assignee and asking for an update from the person that set it to 'in progress'? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From persia at ubuntu.com Wed May 28 07:31:31 2008 From: persia at ubuntu.com (Emmet Hikory) Date: Wed, 28 May 2008 16:31:31 +0900 Subject: Patch Statuses in Launchpad (re-visited) In-Reply-To: <87k5he6hcq.fsf@faui44a.informatik.uni-erlangen.de> References: <483AC2D9.40701@ubuntu.com> <483D004B.50101@ubuntu.com> <87k5he6hcq.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <9bd2f8970805280031g48176f9bv2a79d25fabb74bcc@mail.gmail.com> Reinhard Tartler wrote: > Moreover we need to make sure that such bugs have the assignee field set > properly because of two reasons: > - bugs set to "Incomplete" are subject to expiration > - we need to make clear who needs to act next on the bug. In that case > we want the patch submitter to work on the patch, not the reporter. I don't want to limit the next person to touch the bug to the patch submitter. I've worked on a number of bugs where more than one person works on the patch, a third (or fourth) person generates a debdiff, and yet someone else uploads. I think there are three interesting cases where a patch might need attention: 1) Where a patch is an incomplete or suboptimal solution, and could be improved 2) Where a patch can be tested by others to confirm the solution 3) Where a patch needs to be updated to match the current development repositories (I deliberately exclude those cases where there is additional workflow involved) In case #1, I'd hope that anyone with the requisite technical skill and familiarity would submit a new patch for review. In case #2, I'd hope that a number of people would inspect the patch and comment, and in case #3, I don't think the submitter should be penalised for working on a supported release and that the update ought be done by someone willing to work (and test) with the development release. Daniel Holbach wrote: > I repeat: untagging the "patch flag" is easier, but we lose information > that is very important if we don't want to lose possible solutions in > the 40k bugs we have open anyway. Of these 40k bugs, only about 4000 have described solutions or workarounds, and of these only about 2000 are in the form of a patch that applies to some version of the source (which may not be the current source). While it is nice not to lose information, the patch flag is not the appropriate means to indicate a bug has a known solution (as many solutions are not sent as patches, and may not need them), and for those people interested in reviewing patches, retaining this does not help understand what patches need review. If the removal of the patch flag is used as an indicator that the attached "patch" is not of any use, that has value in excess of the value retained by remembering that someone attached a useless patch. On the other hand, this is why I also advocate the use of the patch tag in combination with the patch flag, such that those flagged, but not tagged, are in need of review/improvement (and are not considered useless), and those tagged are in need of review/upload. While the term "review" is common in both places, I suspect the nature of the reviews to differ between determining whether a given attachment provides part or all of a solution and whether a given patch is the solution that belongs in the repositories. Detailed meanings for these states for specific bugs are likely best captured in bug comments (which we ought be reading before taking action on a bug). -- Emmet HIKORY From daniel.holbach at ubuntu.com Wed May 28 07:39:30 2008 From: daniel.holbach at ubuntu.com (Daniel Holbach) Date: Wed, 28 May 2008 09:39:30 +0200 Subject: Patch Statuses in Launchpad (re-visited) In-Reply-To: <87k5he6hcq.fsf@faui44a.informatik.uni-erlangen.de> References: <483AC2D9.40701@ubuntu.com> <483D004B.50101@ubuntu.com> <87k5he6hcq.fsf@faui44a.informatik.uni-erlangen.de> Message-ID: <483D0C32.2090209@ubuntu.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Reinhard Tartler schrieb: > Moreover we need to make sure that such bugs have the assignee field set > properly because of two reasons: > - bugs set to "Incomplete" are subject to expiration > - we need to make clear who needs to act next on the bug. In that case > we want the patch submitter to work on the patch, not the reporter. We could make it "In Progress" and assign to the patch submitter. Unfortunately searching for "any assignee, but not 'nobody'" does not work in Launchpad Bugs. If only offers "Nobody", "Doesn't matter" and an explicit assignee. Which other possibility do we have? > This does only work if: > - upstream uses a bugtracker at all > - the bugtracker is supported by launchpad > - the bugtracker registered with launchpad properly In those cases you can still use an empty upstream task to mark the bug as "this affects upstream" - of course you need to check manually if it was accepted upstream. The Launchpad query for that would be https://launchpad.net/ubuntu/+bugs?field.status_upstream=pending_bugwatch&field.status_upstream=resolved_upstream&field.status_upstream=open_upstream&field.has_patch=on which lists bugs - with empty upstream task (this affects upstream) - with solutions that were forwarded upstream - with solutions that were accepted upstream > I'd be interested to know how many bugs with patches are affected by > these problems though. Hm? Ask Sébastien how often he asks patch submitters to get their stuff upstream first because the patches are just too big to carry them as a delta. I think this is pretty common if you don't deal with "./debian/-only patches". > I think we need to investigate these 40k bugs in more detail. I hope we > can classify them more, so it become easier to batch process them. Sure, both needs to happen - we should definitely try not to lose information though. > I > furthermore think this is a discussion that should definitly happen > within the ubuntu developer community, and not solely on the bugsquad > list. I sent the mail to ubuntu-devel@ separately because I messed up the sender address. Sorry for that - still the proposal went to the devel mailing list. Have a nice day, Daniel - -- My 5 today: #234288 (grub2), #234992 (apturl), #235373 (mtools), #229864 (ttf-unfonts), #234457 (ygraph) 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 iD8DBQFIPQwyRjrlnQWd1esRAhBjAJ9RtW9RpTqOWMH7eo7L1wFNXQhAwwCbBqiJ /bKgFswHvpMuoUOX7vnEU1g= =5Zy7 -----END PGP SIGNATURE----- From daniel.holbach at ubuntu.com Wed May 28 08:19:26 2008 From: daniel.holbach at ubuntu.com (Daniel Holbach) Date: Wed, 28 May 2008 10:19:26 +0200 Subject: Patch Statuses in Launchpad (re-visited) In-Reply-To: <9bd2f8970805280054m16363388kfc38cc238475879a@mail.gmail.com> References: <483AC2D9.40701@ubuntu.com> <483D004B.50101@ubuntu.com> <87k5he6hcq.fsf@faui44a.informatik.uni-erlangen.de> <483D0C32.2090209@ubuntu.com> <9bd2f8970805280054m16363388kfc38cc238475879a@mail.gmail.com> Message-ID: <483D158E.4020007@ubuntu.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Emmet Hikory schrieb: > Daniel Holbach wrote: >> In those cases you can still use an empty upstream task to mark the bug >> as "this affects upstream" - of course you need to check manually if it >> was accepted upstream. > <...> >> Reinhard Tartler schrieb: >>> I'd be interested to know how many bugs with patches are affected by >>> these problems though. >> Hm? Ask Sébastien how often he asks patch submitters to get their stuff >> upstream first because the patches are just too big to carry them as a >> delta. >> >> I think this is pretty common if you don't deal with "./debian/-only >> patches". > > This is very upstream-specific. Well, it's the "patch needs upstream review" case. :-) > In cases where there are large > active upstream communities (e.g. GNOME, KDE), this may make sense. > For the vast majority of packages, upstream is relatively inactive, or > even if active, unlikely to make a release within the next six months. > While patches are appreciated, they often do not get review, so much > as belated integration. There are also a number of packages for which > upstream is unwilling to consider a patch (even for a bug that makes > the package unusable) if it is not submitted against VCS trunk (in > some cases where there has been no release in > 1 year). I'm not sure I can agree with your view on how most upstream developers deal with their code, releases and patches. In most cases a new release is not even necessary, a "yes, this looks good - go ahead and apply it for version x.y.z" is good enough. The point is that we have patches where we are not the best to judge if it's good to integrate it - in all cases upstream are the ones with the best knowledge of their own code. > Note that some of this is mitigated by considering Debian > upstream, and working with Debian maintainers to get patches into > Debian, but there are some cases where changes required to prevent > FTBFS in Ubuntu would cause FTBFS in Debian, or similar arrangements, > even outside debian/. Further, not all Debian maintainers are very > active, and applying a patch in Debian when a maintainer is away can > be very complicated for those not familiar with Debian processes. Some documentation on when to forward which portion to whom would be great. As a rule of thumb: if a patch only concerns ./debian/ it might make sense to send it to Debian too - depending on https://wiki.ubuntu.com/UbuntuPackagingChanges else it's good to let upstream know about it or ask them for advice. Maybe I should have made this clearer in my initial proposal. As I see it, there are a few reactions we can have towards submitted patches: - it's OK - upload it (and ask to send it to Debian/upstream) - it's NOT OK - we ask for clarification, a fix or a rewrite - we don't know - we ask Upstream for advice I can't tell how often which case will occur, but we should have a solution in place that can deal with all of them and that does not lose us information. "bugs-with-patches-attached ZERO" FTW! Have a nice day, Daniel - -- My 5 today: #234288 (grub2), #234992 (apturl), #235373 (mtools), #229864 (ttf-unfonts), #234457 (ygraph) 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 iD8DBQFIPRWORjrlnQWd1esRAhJLAJ9/053d7rvCb5+o5mxm+POUIsUdSACfcEqO kMoWQctXH41nRzSRK+K0ums= =vbiT -----END PGP SIGNATURE----- From kirrus at kirrus.co.uk Wed May 28 09:17:07 2008 From: kirrus at kirrus.co.uk (Johnathon Tinsley) Date: Wed, 28 May 2008 10:17:07 +0100 Subject: Request someone to check over my SRU submission Message-ID: <483D2313.4090005@kirrus.co.uk> Hello all, Can someone take a brief look at this one, and just make sure I've not missed any processes out in this SRU submission? https://bugs.launchpad.net/ubuntu/+source/insight/+bug/110387 Thanks, Johnathon From jw+debian at jameswestby.net Wed May 28 10:26:43 2008 From: jw+debian at jameswestby.net (James Westby) Date: Wed, 28 May 2008 11:26:43 +0100 Subject: Request someone to check over my SRU submission In-Reply-To: <483D2313.4090005@kirrus.co.uk> References: <483D2313.4090005@kirrus.co.uk> Message-ID: <1211970403.6483.164.camel@flash> On Wed, 2008-05-28 at 10:17 +0100, Johnathon Tinsley wrote: > Hello all, > > Can someone take a brief look at this one, and just make sure I've not > missed any processes out in this SRU submission? > > https://bugs.launchpad.net/ubuntu/+source/insight/+bug/110387 Hi, One thing I can see is that the TEST CASE is only half complete, it needs to have the part after installing the new version, i.e. how to check that it is fixed. Also, there need to be patches on the bug for each of the versions that the SRU is going to go to. Also, the problem still appears to be present in Intrepid, at least the offending line is still in debian/rules. For an SRU it needs to be fixed there first. Reporting it to Debian would be great as well. Lastly, I'm not sure why it was declined for Hardy, it seems like it should be fixed there. I'm trying to find out from Daniel why he did it, but I think he is walking the dog at the moment. I realise that SRUs are quite a bit of work, thanks for taking the time. Thanks, James From emmet.hikory at gmail.com Wed May 28 07:54:21 2008 From: emmet.hikory at gmail.com (Emmet Hikory) Date: Wed, 28 May 2008 16:54:21 +0900 Subject: Patch Statuses in Launchpad (re-visited) In-Reply-To: <483D0C32.2090209@ubuntu.com> References: <483AC2D9.40701@ubuntu.com> <483D004B.50101@ubuntu.com> <87k5he6hcq.fsf@faui44a.informatik.uni-erlangen.de> <483D0C32.2090209@ubuntu.com> Message-ID: <9bd2f8970805280054m16363388kfc38cc238475879a@mail.gmail.com> Daniel Holbach wrote: > In those cases you can still use an empty upstream task to mark the bug > as "this affects upstream" - of course you need to check manually if it > was accepted upstream. <...> > Reinhard Tartler schrieb: >> I'd be interested to know how many bugs with patches are affected by >> these problems though. > > Hm? Ask Sébastien how often he asks patch submitters to get their stuff > upstream first because the patches are just too big to carry them as a > delta. > > I think this is pretty common if you don't deal with "./debian/-only > patches". This is very upstream-specific. In cases where there are large active upstream communities (e.g. GNOME, KDE), this may make sense. For the vast majority of packages, upstream is relatively inactive, or even if active, unlikely to make a release within the next six months. While patches are appreciated, they often do not get review, so much as belated integration. There are also a number of packages for which upstream is unwilling to consider a patch (even for a bug that makes the package unusable) if it is not submitted against VCS trunk (in some cases where there has been no release in > 1 year). Note that some of this is mitigated by considering Debian upstream, and working with Debian maintainers to get patches into Debian, but there are some cases where changes required to prevent FTBFS in Ubuntu would cause FTBFS in Debian, or similar arrangements, even outside debian/. Further, not all Debian maintainers are very active, and applying a patch in Debian when a maintainer is away can be very complicated for those not familiar with Debian processes. -- Emmet HIKORY From ubuntu at kitterman.com Wed May 28 10:18:03 2008 From: ubuntu at kitterman.com (Scott Kitterman) Date: Wed, 28 May 2008 6:18:03 -0400 Subject: Patch Statuses in Launchpad (re-visited) In-Reply-To: <483CFFC2.6050201@canonical.com> References: <483AC2D9.40701@ubuntu.com> <483CFFC2.6050201@canonical.com> Message-ID: <72486-SnapperMsgD8DB99B6C462E1FD@[70.198.224.231]> On Wed, 28 May 2008 08:46:26 +0200 Daniel Holbach wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hello everybody, > >I thought about my initial proposal again and must say I wasn't too >happy with the use of tags either, I still think though that it's >vitally important to not lose bugs that have proposed solutions in the >mediocrity of the huge list of bugs (all bugs marked as medium, all bugs >marked as new). In every case I can recall where I've worked with a submitter, they've come back and fixed whatever issues I came up with during sponsorship review. Such bugs aren't lost, just handed back to the submitter for further work. I don't think I've run across a case where someone submitted an incomplete patch, didn't fix it, and then someone else came along and made use of it. I'm sure this happens, but I believe it to be extremely rare. >I'd like to make use of three list in my new proposal: >https://launchpad.net/ubuntu/+bugs?field.has_patch=on would be the >general lists of bugs with patches. > >Daniel Holbach schrieb: >> - use "patch-needs-work" if you reviewed a patch and it needs more work >> (or you flat-out rejected it) > >Can we agree on using "Incomplete" in this case? >https://launchpad.net/ubuntu/+bugs?field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.has_patch=on >then would be the list of bugs with patches that still need work. There was some discussion from Launchpad developers at UDS about turning the bug janitor back on. We don't, I'm pretty sure, want to expire the bug in such cases as it's the patch that's incomplete, not the bug. >> - use "patch-went-upstream" if you forwarded it upstream to get their >> input before uploading it to Ubuntu > >If we add an upstream task, we could make use of >https://launchpad.net/ubuntu/+bugs?field.status_upstream=open_upstream&field.has_patch=on >that are forwarded upstream and still need upstream input and >https://launchpad.net/ubuntu/+bugs?field.status_upstream=resolved_upstream&field.has_patch=on >the patches that were forwarded upstream and the upstream bugs that have >been resolved. I think an upstream bug task is sufficent in this case. You really can't understand the status of an upstream bug/patch review without reading their bug, so I don't think the added complexity adds much. >I repeat: untagging the "patch flag" is easier, but we lose information >that is very important if we don't want to lose possible solutions in >the 40k bugs we have open anyway. My fundamental dis-agreement is that this information is very important. I see some value, but find considerably more value in in keeping the process simple/usable. Scott K From wolfger at gmail.com Wed May 28 16:13:00 2008 From: wolfger at gmail.com (Wolfger) Date: Wed, 28 May 2008 12:13:00 -0400 Subject: [off topic] Anyone in/near Aalen, DE? Message-ID: <3b00b3330805280913j452aa8desf3c521255182dd0c@mail.gmail.com> I'll be making a business trip there in a few weeks. Would be cool if I could meet some people while I'm there. Please reply off-list, so as not to spam everybody like I just did :-) -- Wolfger http://wolfger.wordpress.com/ My 5 today: #138272 (debian-installer), #177667 (gcc-4.2), #173477 (linux-source-2.6.22, linux), #187378 (gcc-4.2), #174565 (linux-source-2.6.22, linux) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day From siretart at ubuntu.com Wed May 28 16:36:05 2008 From: siretart at ubuntu.com (Reinhard Tartler) Date: Wed, 28 May 2008 18:36:05 +0200 Subject: Proposed changes to workflow bug management In-Reply-To: <200805281217.17272.stefan.potyra@informatik.uni-erlangen.de> (Stefan Potyra's message of "Wed, 28 May 2008 12:17:06 +0200") References: <200805261545.36643.ubuntu@kitterman.com> <20080528063123.GF6570@piware.de> <483D2528.6020900@ubuntu.com> <200805281217.17272.stefan.potyra@informatik.uni-erlangen.de> Message-ID: <871w3m1j4a.fsf@faui44a.informatik.uni-erlangen.de> Stefan Potyra writes: > Also I don't believe that workflow bugs should be a red area for triagers. > During motu-relase work for hardy, I've seen one or two occurances, where > someone fixed a bug state from a bad filed freeze exception request, and I > greatly appreciated this! Excellent point. There is no need to exclude triagers from workflow bugs. In fact, it might be that workflow bugs are the easiest ones when it comes to dectect if the bug is missing information, is assigned to the wrong team or general procedures have not been followed. Of course it means that you have to understand what the procedures are in the first place, but there is no black magic here. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 From persia at ubuntu.com Wed May 28 20:52:09 2008 From: persia at ubuntu.com (Emmet Hikory) Date: Thu, 29 May 2008 05:52:09 +0900 Subject: Proposed changes to workflow bug management In-Reply-To: <72711-SnapperMsgD8DB99B6C4636EE8@75.223.206.90> References: <200805261545.36643.ubuntu@kitterman.com> <20080528063123.GF6570@piware.de> <483D2528.6020900@ubuntu.com> <200805281217.17272.stefan.potyra@informatik.uni-erlangen.de> <871w3m1j4a.fsf@faui44a.informatik.uni-erlangen.de> <72711-SnapperMsgD8DB99B6C4636EE8@75.223.206.90> Message-ID: <9bd2f8970805281352n6d0ab15fk410380cea1ffd1a7@mail.gmail.com> Scott Kitterman wrote: > Agreed. I think "Don't mark on bugs you don't understand" is a much more > useful approach than setting rules on which classes of people can touch > which kinds of bugs. Just to be fair, and in reference to some of the discussions that were partly responsible for initiating these threads, this ought have a corresponding "educate rather than complain" for those cases where bugs are handled in a non-ideal manner. While we've been discussing primarily workflow bugs, the same can also be seen in other cases where people less familiar with our various launchpad processes (for any team) may make an incorrect adjustment. In addition, I think it is important to define "understand" to be about the type of bug, and how it relates to the package. I don't believe it is necessary to understand the specific issue that causes the bug in order to start working on it (especially so for those who are not also developers), although I can see value with this rule where it is more general: compiled code often benefits from a stacktrace, interpreted code often benefits from a backtrace, display or sound issues often benefit from certain files, etc. All of these may be crashes, but the information required to accurately determine the problem differs. Similar guidelines apply to any class of bugs (workflow, crashes, typos, unexpected behaviour, feature requests, etc.). Similarly, different groups of packages are handled differently, so for example GNOME bugs are usually pushed upstream, Games bugs are usually pushed to the Debian Games team, Install/Upgrade bugs are often fixed directly in Ubuntu, and these differences are also in the repetoire of things worth learning, and things worth educating others about. -- Emmet HIKORY From brian at ubuntu.com Thu May 29 17:21:28 2008 From: brian at ubuntu.com (Brian Murray) Date: Thu, 29 May 2008 10:21:28 -0700 Subject: Additional Bug Reports Message-ID: <20080529172128.GX7382@murraytwins.com> I've setup some additional bug reports[1] that I've found useful and interesting and thought you might too. There is a report for bugs with ten or more duplicates. Due to the fact that they have duplicates at all they should probably be confirmed. Additionally, if the 'master' bug report is private less people will be able to see it so it should be not marked as private if possible. Also if the 'master' bug report is old I think it'd be worthwhile to update the description of it with the latest version of the package that has the bug. There are also reports for the oldest bug in a certain state, where age is measured by the date reported. Naturally, it would helpful to move any bug in those reports along in the triaging process. The Fix Committed bug reports are probably the most tricky though so feel free to ask for help on this list or in #ubuntu-bugs. All of these reports are updated daily. Let's try and make the oldest bugs not so old! [1] http://people.ubuntu.com/~brian/reports/database/ -- 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 May 29 19:03:48 2008 From: mpt at canonical.com (Matthew Paul Thomas) Date: Thu, 29 May 2008 20:03:48 +0100 Subject: Patch Statuses in Launchpad (re-visited) In-Reply-To: <483D0C32.2090209@ubuntu.com> References: <483AC2D9.40701@ubuntu.com> <483D004B.50101@ubuntu.com> <87k5he6hcq.fsf@faui44a.informatik.uni-erlangen.de> <483D0C32.2090209@ubuntu.com> Message-ID: <483EFE14.5060206@canonical.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Holbach wrote on 28/05/08 08:39: >... > Unfortunately searching for "any assignee, but not 'nobody'" does not > work in Launchpad Bugs. If only offers "Nobody", "Doesn't matter" and an > explicit assignee. >... I've reported this problem. 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 iD8DBQFIPv4U6PUxNfU6ecoRAgZvAKDJmThhtRCUf5/waO8SFRzHecaesQCdGz2N RKjNFY7Cpwdkl6r2tgVnnLQ= =oOeF -----END PGP SIGNATURE----- From mok at bioxray.au.dk Thu May 29 21:49:42 2008 From: mok at bioxray.au.dk (Morten Kjeldgaard) Date: Thu, 29 May 2008 23:49:42 +0200 Subject: Proposed changes to workflow bug management In-Reply-To: References: <200805261545.36643.ubuntu@kitterman.com> <200805262209.54215.ubuntu@kitterman.com> <483BBD5A.4030107@ubuntu.com> <9bd2f8970805270124w5dcedc4bp406bae36bda4666d@mail.gmail.com> <87skw4az78.fsf@faui44a.informatik.uni-erlangen.de> <483BD772.8070703@ubuntu.com> <87k5hgaved.fsf@faui44a.informatik.uni-erlangen.de> <1211891495.8844.71.camel@cunning> <87fxs3bzk3.fsf@faui44a.informatik.uni-erlangen.de> <1211909258.7648.25.camel@cunning> Message-ID: <9B823F75-BB5C-416A-ACCA-8368D8D51C83@bioxray.au.dk> On 27/05/2008, at 20.44, Caroline Ford wrote: > Launchpad tags are useless - just a long list of noise, most with > 0s afterwards. Gee, Caroline, I love your positive and productive remarks... Seriously, this is a discussion on how to improve the workflow. So, tags are useless, period, until the end of the universe? I've not been involved in this discussion long enough to understand your bitter gripes, but why not use your significant experience to help improve things, instead of arrogantly repudiating anything but your own superior intellect? Cheers, Morten From mok at bioxray.au.dk Fri May 30 05:16:10 2008 From: mok at bioxray.au.dk (Morten Kjeldgaard) Date: Fri, 30 May 2008 07:16:10 +0200 Subject: Proposed changes to workflow bug management In-Reply-To: <73101-SnapperMsgD8DB99B6C464DBF3@[75.192.181.21]> References: <200805261545.36643.ubuntu@kitterman.com> <200805262209.54215.ubuntu@kitterman.com> <483BBD5A.4030107@ubuntu.com> <9bd2f8970805270124w5dcedc4bp406bae36bda4666d@mail.gmail.com> <87skw4az78.fsf@faui44a.informatik.uni-erlangen.de> <483BD772.8070703@ubuntu.com> <87k5hgaved.fsf@faui44a.informatik.uni-erlangen.de> <1211891495.8844.71.camel@cunning> <87fxs3bzk3.fsf@faui44a.informatik.uni-erlangen.de> <1211909258.7648.25.camel@cunning> <9B82 3F75-BB5C-416A-ACCA-8368D8D51C83@bioxray.au.dk> <73101-SnapperMsgD8DB99B6C464DBF3@[75.192.181.21]> Message-ID: On 30/05/2008, at 0.17, Scott Kitterman wrote: > Sarcasm isn't particularly useful here. Her assessment was harsh, > but I You are right, I am sorry Caroline. > think reasonably accurate with Tags as they are now. Tag based > discovery > is not, IMO, a good basis for process improvement without a redesign. Redesign is the key phrase here. Tags may not be useful currently, but that's only because they've not been systematically employed. Basically, tags are small strings that can be used to filter searches on LP. They are a design feature that makes it possible to expand the UI in ways that were not originally envisaged when the schema was designed. So tags are not at all "useless". We have a huge database of bugs, which are very different in character, but all the bugs are data points in the health status of Ubuntu. This discussion should really be about how to mine this database for useful information. It is actually a fascinating problem that we are trying to solve, which has never been done before, because no one has ever had access to such a database before. For example, it was mentioned in another discussion that patch statuses are not necessarily the same as the bug status. A patch can be "invalid" where the bug itself is not. The connotation of this is that there are not enough status markers for bugs; there really should be one for patches as well. However, a solution to this problem could be achieved using tags in a systematic way; and this use could in principle be hard-wired into the GUI. My point is, that if it can be agreed upon what searches (filterings) of the data we need to solve particular problems in the treatment, classification or workflow of bugs, that can be accomplished using tags. Therefore, the main objective IMHO is to establish what kind of bug- filtering criterea would be useful to the various teams. What common bug properties would be useful to see? With tags, these filterings can be tried out in an ad hoc manner, and if proven useful, incorporated more formally. > and training aids for new troagers. I think triagers should start on > things they are familiar with and expand out as they gain > experience. If > triagers would start narrowly, expand outwards as they learn, and > stop and > ask if they hit something unfamilair, I think the incidence of > issues with > workflow bugs would drop to acceptable levels. I agree. But this does not exclude that we also attempt to incorporate the accumulated experience and knowledge of seasoned bug- triagers and developers into the UI of the LP database. Cheers, Morten From brian at ubuntu.com Fri May 30 19:43:41 2008 From: brian at ubuntu.com (Brian Murray) Date: Fri, 30 May 2008 12:43:41 -0700 Subject: Return of the Hug Day - 03 June 2008 Message-ID: <20080530194341.GD7382@murraytwins.com> We've had a bit of a break in the Hug Days since the release of Hardy Heron, but now they are back! On Tuesday, June 3rd, the focus will be on those pesky bugs without a package. The number of them has grown to about 3600 but the rate of newly reported bugs without a package is slowing. We'll focus on assigning these bugs to the correct package and gathering more information from reporters. 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/20080603 Our goal is to deal with all of the bugs on that list. I've also added a new section to the list of bugs - bugs with jpeg attachments. Who knows what the picture is of but hopefully it'll help get the bug assigned to a package! So on 03 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, 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! 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 susana.pereira at gmail.com Sat May 31 15:58:24 2008 From: susana.pereira at gmail.com (Susana Pereira) Date: Sat, 31 May 2008 16:58:24 +0100 Subject: Changes to the triage guide - translation bugs Message-ID: <1212249504.6100.77.camel@riemann> Hi, I brought this up in #ubuntu-bugs today and was told to send an email to these lists. I only subscribe the translators list and not the bugsquad so if you answer from that list please CC me. Currently, the triage guide instructs people to close translation bugs as invalid[1] and redirect the reporter to rosetta[2]. In my opinion this wrong because: 1) They are real issues that need to be fixed; 2) Unless the reporter is a member of the translators team, his/her changes are going to be marked as suggestions. Rosetta does not warn translators about new suggestions and it takes a member to mark them as permanent translations; 3) You assume the reporter knows the package where that string is from which is, sometimes, not that obvious; 4) By closing the bug you are making sure that the only people who can fix it will not see it; I think it would be much better to tell triagers to subscribe the appropriate translation team. I have done this many times and usually translators are very fast at fixing bugs once they know they exist. I've seen many developers doing this too, but general triagers just close the bugs. 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. 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. Cheers, Susana [1]"The best thing to do here is to politely decline the report while thanking the user for submitting it. There are some useful Bugs/Responses that you can use in these cases." https://wiki.ubuntu.com/Bugs/HowToTriage#head-9616b38c0082ca6cf24ee047abf79d9999db1e18 [2]"Thank you for taking the time to report this bug and helping to make Ubuntu better. However, Ubuntu gets its translations from the translations portion of Launchpad ([WWW] http://translations.launchpad.net/ubuntu/), where translation teams work on making Ubuntu more useful in their language. If you want to change a translation in Ubuntu there is the right place." https://wiki.ubuntu.com/Bugs/Responses#head-fb119da008af90df2a8efdc1e7b093af95deb720 From ogmaciel at ubuntu.com Sat May 31 20:10:08 2008 From: ogmaciel at ubuntu.com (Og Maciel) Date: Sat, 31 May 2008 16:10:08 -0400 Subject: Changes to the triage guide - translation bugs In-Reply-To: <1212249504.6100.77.camel@riemann> References: <1212249504.6100.77.camel@riemann> Message-ID: <4841B0A0.8050003@ubuntu.com> 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)