pjf at perltraining
Nov 8, 2009, 10:14 PM
Post #1 of 1
(153 views)
Permalink
|
|
[Planning] The Great 5.12 Bug Triage
|
|
G'day p5p,
The other day Jesse asked me if I'd be willing to sort out some 1,500
outstanding bugs at http://rt.perl.org/rt3/Public . In particular, I've
been asked to look at them all to see if there's any show-stoppers for 5.12.
I've accepted this task, with the intention to personally inspect as few of
these bugs as possible. Instead, I hope to make people feel loved if they
triage the bugs for me, most likely by cajoling Perl Mongers groups and my
existing volunteer base. I'm hoping to parcel up bugs into chunks of about
20 or so for individual volunteers to examine.
If we're optimising to locate 5.12 showstoppers, then I believe we generally
want to examine tickets with the following guidelines:
* Tickets that have a (fatal|High) priority first. Let's face it, a bug
submitted with "low" priority is unlikely to be a showstopper.
* Recent tickets over old tickets. A recent ticket is more likely to
represent a current bug. Eight year old tickets are much less likely
to still be current, or have such limited impact that they're not likely
to be showstoppers.
With this in mind, while it's *nice* to triage all 1,500 bugs, we're likely
to get most of our hits on our primary goal (5.12 showstoppers) relatively
quickly.
Of course, if we're examining tickets for 5.12 showstoppers, it would be
lovely to do a bit more clean-up while we're at it. Fixed bugs get closed.
Bugs with patches get those patches looked at. Eight year old bugs on Perl
5.004 on some obscure platform that's already end-of-lifed get closed (please!).
Volunteers who have RT access can make tweaks directly, but even if
*everyone* has RT access, we still need a way to record bugs as having been
triaged, so we don't duplicate effort. And some of our users won't have RT
access[1], although I believe that *anyone* can add to RT via the e-mail
interface.
So, the plan is to have a template. It records the template version (useful
for automated tools), and any relevant information, such as if it's a
showstopper (yes/no/maybe), if the bug should be closed, if it can be
reproduced, and so on.
My questions for you, dear reader:
* Is there something more suitable than a template? Keep in mind that I'm
going to be dealing with a wide variety of volunteers. Simplicity is key.
* What constitutes a "showstopper"? I imagine some things will fall into a
"maybe" category, which indicates it requires further review.
* What information should be on the template? I expect practically all
fields will be optional, but should include:
* 5.12 showstopper? (Yes/no/maybe)
* Can/Can't be reproduced (version, platform)
* Hey look at this patch!
* Needs attention (and reason why).
For people without RT access:
* Should be closed? (Fixed/not a bug/not supported/etc)
* Merge with...
* Change status to...
* Adjust priority/etc/other fields.
Templates will, of course, also support free-form comments.
* Do you have any other great ideas that I should be thinking about?
I'm planning to kick off the first bug triage this Wednesday evening
(GMT+11) at Melbourne Perl Mongers.
Suggestions, ideas, comments, criticisms and beer all welcome.
Cheerio,
Paul
[1] If I can hand out RT access en masse and with little work, let me know!
But for the moment, I'm assuming that's non-trivial.
--
Paul Fenwick <pjf [at] perltraining> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia | Fax: +61 3 9354 2681
|
