[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Basic questions about the triage process
From: |
Andrew Hyatt |
Subject: |
Re: Basic questions about the triage process |
Date: |
Tue, 29 Dec 2015 19:22:27 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (darwin) |
Eli Zaretskii <address@hidden> writes:
>> From: Andrew Hyatt <address@hidden>
>> Date: Tue, 29 Dec 2015 00:40:08 -0500
>>
>> I've put together my notes into a file I stuck in the admin section.
>
> Thanks. A few comments below.
>
>> +* The what and why of bug triage
>> +
>> +Bugs have to be regularly looked at and acted upon. Not all bugs are
>> +critical, but at the least, each bug needs to be regularly re-reviewed
>> +to make sure it is still reproducible. A large backlog of bugs is
>> +disheartening to the developers, and a culture of ignoring bugs is
>> +harmful to users, who expect software that works.
>
> This paragraph is probably better to move to CONTRIBUTE. It should
> point to this file, which in turn should describe only the triage
> itself, not its importance.
OK, I've done so (see the modified patch I've attached). This probably
needs a bit more work since we want to talk about more kinds of triage
as well (notably the triaging of new bugs), eventually.
>
>> +The goal of this triage is to prune down the list of old bugs, closing
>> +the ones that are not reproducible on the current release.
>
> I think triage is more than that: it should also strive to classify
> the bugs according to their importance.
Yes, but isn't that more about triaging new bugs? I'm not writing about
that yet - but if someone tells me how to triage new bugs I'm happy to
write it up.
>
>> + 1. To start, enter debbugs mode (either debbugs-gnu or debbugs-org), and
>> + accept the default list option of bugs that have severity serious,
>> + important, or normal.
>> + 2. This will also show closed bugs that have yet to be archived. You can
>> + filter these out in debbugs-gnu with "x" (debbugs-gnu-toggle-suppress).
>
> Triage can be done via a Web browser as well. I suggest to mention
> debbugs-gnu as one possibility, perhaps the preferred one, but not the
> only one.
Done.
>
>> + 3. For each bug, do the following:
>> + - Read the mail thread for the bug. Find out if anyone has been able to
>> + reproduce this on the current release.
>> + - If someone has been able to, then your work is finished for this bug.
>
> Again, having the bug reproducible is not the end of triage, at least
> not in general. It is a good idea to use your judgment to decide
> whether the bug is really a bug (and if so, how important it is), a
> request for a new feature, or simply a rant. debbugs.gnu.org supports
> tags for recording the results of this process; it would be good if at
> least some bugs got tagged accordingly as result of the triage.
Again, I think this right, but for new bug triage which I haven't
written up yet. For the bug backlog, I'm assuming someone has already
taken a pass at each bug.
>
>> + - If you can reproduce, then reply on the thread (either on the
>> original
>> + message, or anywhere you find appropriate) that you can reproduce
>> this on
>> + the current release.
>
> Here, I'd suggest to request adding relevant details. Sometimes bug
> reports don't provide backtraces, or don't even describe the recipe in
> sufficient detail. If the triage supplies these details, let alone if
> you can come up with a simpler reproducer, adding this information
> will be of great value to those who will come after you to try
> resolving the bug.
>
> Also, if the description isn't detailed enough, it might be a good
> idea to ask for more detailed description, because the stuff that was
> left out might be the reason for not being able to reproduce the bug
> in the first place.
Done (although I split this up into two parts - one new bullet point,
another as part of the text on what to do if you can reproduce the issue).
>
>> + - If you can't reproduce, but the bug is newer than 2 years old, state
>> that
>> + you can't reproduce it on the current release, ask if they can try
>> again
>> + against the current release.
>
> There's a tag for that, I believe.
We can just use the "unreproducible" tag. Sounds like a good idea.
I'll add that.
>
>> + 4. Your changes will take some time to take effect. After a period of
>> minutes
>> + to hours, you will get a mail telling you the control message has been
>> + processed. At this point, you and everyone else can see your changes.
>
> That mail can also say there were errors, something to mention here, I
> think.
Mentioned, but I'm a bit at a loss on what to say if there were errors.
>
> Thanks again for working on this (and on the triage itself).
No problem. I've also removed, by popular demand, the distinction
between pre-and-post 2 years old. Now we'll always just ask first.
I've also fixed a few spelling and grammar errors.
0001-Add-a-file-detailing-how-to-triage-bugs.patch
Description: Version 2 of triage notes patch
- Basic questions about the triage process, Andrew Hyatt, 2015/12/28
- Re: Basic questions about the triage process, Michael Albinus, 2015/12/28
- Re: Basic questions about the triage process, John Wiegley, 2015/12/28
- Re: Basic questions about the triage process, Andrew Hyatt, 2015/12/29
- Re: Basic questions about the triage process, Eli Zaretskii, 2015/12/29
- Re: Basic questions about the triage process,
Andrew Hyatt <=
- Re: Basic questions about the triage process, Eli Zaretskii, 2015/12/30
- Re: Basic questions about the triage process, Noam Postavsky, 2015/12/30
- Re: Basic questions about the triage process, Eli Zaretskii, 2015/12/30
- Re: Basic questions about the triage process, Michael Albinus, 2015/12/31
- Re: Basic questions about the triage process, Eli Zaretskii, 2015/12/31
- Re: Basic questions about the triage process, Michael Albinus, 2015/12/31
Re: Basic questions about the triage process, Xue Fuqiao, 2015/12/28