Paul Fenwick (p...@perltraining.com.au)

G'day Melb.pm and p5p,

Here's the long overdue report on the great Melbourne Perl Mongers bug triage.

We managed to properly triage an estimated 68 tickets at Melbourne Perl
Mongers (many thanks to Myf White for calculating this), along with about 14
which would have been completely triaged if I had all the meta-tickets
properly set up.  That's about 82 tickets total, which is pretty darn
awesome for a single night and not the world's best wireless access[1].  A
huge thank-you to all the Melbourne.pm volunteers!

If you want to run your own triage event, then here's a few recommendations:

* Work in pairs or small groups.

* Make sure meta-tickets are well-known beforehand.
On http://rt.perl.org/rt3/ these currently are:

* RT 69710 - Perl 5.12.0 - Showstoppers
* RT 70369 - Perl 5.12.0 - Expert assessment required
* RT 70421 - Perl 5.12.0 - Non-critical
 * RT 70371 - Perl 5.005  - End of life
 * RT 70373 - Perl 5.6.x  - End of life

* Have someone on-hand to give people privileges.  Not everyone will have
  them sorted out beforehand.

* It's nice to have 5.10.1 floating around. A lot of old (5.6.x)
  bugs can just be closed if it's fixed in the most recent
  release.

* Break list of bugs into chunks and hand to each group.  This avoids
  double-triage of bugs.

* Go through an example or two as a group on a projector first, if you
  can.

All the best,

Paul

[1] Federation square wifi allows outgoing http, but nothing else.
    No easy hopping on IRC.

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.

G'day Dave / All,

Warning: After a week of OSCON, and a large sleep debt, I'm practically out
of mana.  I apologise for any lack of clarity that may result.

Dave Mitchell wrote:

> Paul, I just pulled in autodie 2.06_01 from CPAN into blead and maint.
> AFAIKT, 2.06_01 is a sync of blead plus the addition of the eval_error
> method, so I'm assuming this is good for 5.10.1.

Ah, the 2.06_01 was pushed to the CPAN from OSCON to make sure my slides
worked on my Friday talk.  I marked it as a dev release because I hadn't put
any work into design or testing of eval_error(), so I best do that now.

Some modules (eg, Text::Balanced) may set $@ on failure, but not actually
throw an exception.  If one tries to apply autodie (with hints) to one of
these modules, the actual error message itself becomes impossible to access.
By the time autodie is formatting error messages, the old $@ is gone,
because autodie has thrown its own exception.

To accommodate these modules, I added eval_error() to the autodie::exception
class.  It contains the contents of $@ at the time autodie threw its own
exception, which means that we can use autodie with modules like
Text::Balanced and still get good looking and informative errors.

The only thing I really want to check is:

  * Is ->eval_error() a sensible method name for this.  I picked it
    as the English name for $@ is $EVAL_ERROR.

I also need to write tests.  I'm exhausted at the moment, so I'd cheerfully
accept patches, but otherwise they'll probably get written somewhere on my
trip to YAPC::EU.

Cheerio,

Paul

Mark Mielke wrote:

> How does it trip them up? I deal with newbies all the time and in two
> decades, I only remember having to explain ' once due to it "tripping
> somebody up".

Beyond hello world, the first exercise our students write involves printing
their name and favourite colour.  At this stage they know basic scalars and
string interpolation, but look what happens:

 my $name   = "Paul";
my $colour = "Black";

say "$name's favourite colour is $colour";

  Name "name::s" used only once: possible typo at - line 7.

One's first experience with a new language should not be corrupted output
and a hard to understand warning.

Personally, I've had ' cause me many more headaches (always inside strings)
than I've found legitimate uses (always outside of strings, and usually in
Klingon[1]).

Cheerio,

Paul

[1] And even then Perl doesn't have proper Klingon support.  A trailing
apostrophe causes all sorts of distress.

All the time, both for myself personally, and for newbies, and working with
newbies is my job.

I agree with Yves that its usage in strings at least should be considered
for deprecation.  Despite me having code written in Klingon, I'd be happy to
see it gone entirely.

Cheerio,

Paul