How to Triage: Draft posted on wiki

[Christopher Beland]

(Regarding https://fedoraproject.org/wiki/User:Beland/How_to_Triage )

On Wed, 2009-03-18 at 13:26 -0700, Adam Williamson wrote:
> I'm not sure it's a good idea for the triager to do the work of
> splitting a report which actually deals with multiple issues up into
> separate reports. The problem is that then the triager becomes the
> 'reporter', and it won't be clear to the maintainer that the real
> reporter is actually some guy on the CC list. This could lead to
> confusion. I'd prefer to put the onus on the reporter to split the
> issues up.

I was wondering whether cloning a bug would maintain the reporter?  If
not, then it's probably best for the reporter to file a new bug, unless
the triager can reproduce the problem.

> Generally, this draft does not reference the actual use of the
> GreaseMonkey triage script at all. It would be best for each point at
> which a definite action can take place to mention both what to do
> manually, and - if there is one - what GreaseMonkey script button to
> use. E.g. it shouldn't just say that, once the report is complete, you
> set it to ASSIGNED, but that you can click the script's Triaged button
> to do the work for you.

Not coincidentally, I don't use GreaseMonkey (to keep my system
relatively clean), so I don't see what changes it makes.  If anyone who
does use it would like to insert instructions/references at appropriate
points, that would be a useful addition.  But it seems necessary to also
have sensible instructions for those who don't have it installed.

> I'm not sure about the 'how to handle bugs in multiple versions'
> section. This is a problem it's impossible to solve gracefully in
> Bugzilla, but we should do the best we can. I've found it's difficult to
> handle bugs in multiple versions in a single report - people will get
> annoyed if a significant issue is reported in both 10 and Rawhide, for
> e.g., and fixed in Rawhide then marked as fixed, but never fixed in 10,
> and there's no way to keep this active in Bugzilla.
> 
> The best approach IMHO is separate reports for separate releases; it's
> pretty crappy, but the least bad. This is something we can discuss,
> though. What does everyone else think?

I see three options:
A Maintain one bug report per bug, across all versions
B Maintain one bug report per bug, across all versions, unless a
reporter is advocating for a backport
C Maintain separate bug reports for each version a bug appears in


I generally do (A) for Fedora bugs, is this common practice for other
triagers and maintainers?

Having multiple bugs for the same problem makes it harder to collect
diagnostic information, and seems confusing for maintainers.
Triage-time doesn't seem like a good point to make copies of bugs,
because the fix for all two or three different Fedora versions is likely
to be the same.  Probably the time to make new bugs for specific
versions, if any is when a fix is deployed to at least one version.  

Sometimes developers just deploy fixes to all active versions, in which
case we save a bit of overhead. Sometimes they don't.  At that point, it
seems reasonable to say "If you need a backport to an older supported
version, please reopen this bug and add a comment to this effect and
include your rationale." or "If you need a backport to an older
supported version, please open a new bug against that version.
Reference this bug and simply request that the fix be backported to the
desired version."  In the latter case, the developer can respond
"CLOSED/WONTFIX" or by deploying a backported fix.  Or maybe no one will
actually care, or people will be happy that when the next supported
release comes out, they will get the bugfix (and the version they are
currently using will hit EOL in the not-to-distant future, anyway).  In
that case, we save the overhead of having bugs without advocates in
Bugzilla.

> I'm not sure about the 'optional steps' bit. It's a bit of a weird
> organization. I don't think 'is it an upstream bug?' is optional at all,
> to start with.

Certainly there was disagreement on the list about whether triagers
should be trying to reproduce bugs, which is why I made that optional.

As for the upstream issue, there are really two questions:
* Has the bug been reported upstream?
* Should Fedora volunteers or Red Hat employees fix the bug or just
report it upstream and call it a day?

As a triager, I'd be willing to answer the first question if it would be
useful to developers, but it at least doubles the workload by having to
search through two Bugzillas.  Most of us also won't have the
permissions to do cleanup on the upstream Bugzilla, so that could get a
bit messy.

As for the second question, I always have some hope that the Fedora
package maintainer will produce a patch which they will apply
immediately but send a copy upstream for inclusion there.  I don't
really feel comfortable making decisions about whether or not
Fedora-affiliated maintainers have enough personal time to do a patch
themselves, or they need to pass it on.  And if triagers aren't expected
to have familiarity with the code base (or even be programmers) then
it's hard to say whether a given bug can or should be fixed at the
distribution level or at the source.

> The NEEDINFO section needs to explicitly complete the loop by saying
> that, after marking NEEDINFO, you should follow the progress on the bug
> and complete the triage on it or close it as insufficient info, as
> required. The triager's job is not done once a bug is marked NEEDINFO.

I sort of assume that bugs left in NEEDINFO for long enough will simply
show up on the radar of other triagers who explicitly search for them.
Doesn't seem like the original triager is going to have any special
expertise at that point, and it's also possible a different triager
might attempt to reproduce or supply the requested information
themselves.

On a practical level, there's no guarantee that the original triager
will even be still doing triage in 30 or 60 days, so I wouldn't count on
them to take ownership of a given bug for that long.


> well, that's most of my comments for now :) wdyt? I can adjust the draft
> with my proposed changes, if you like.

Feel free.  For the places where we have policy decisions to make, it
might actually be useful to have two or three alternative versions right
there on the page that we can choose between or at least use as a
starting point for discussion.

-B.