Re: Basic questions about the triage process

[Eli Zaretskii]

> From: Andrew Hyatt <address@hidden>
> Cc: address@hidden
> Date: Tue, 29 Dec 2015 19:22:27 -0500
> 
> >> +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.

You assume that old bugs already underwent this procedure, and if they
did, their category is still correct.  But neither of these assumption
is necessarily true.  Some bugs were triaged, others (I suspect most
of them) were not.  Moreover, their current category might very well
be inaccurate, certainly if many years went by.

So I think some effort should go into verifying that a bug does have a
category that we still think to be correct.

> >> +  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.

One needs to read the error message and resubmit the control message
modified as appropriate.  E.g., one example I tend to bump into is
when I merge a bug with another one, and debbugs refuses because their
state is different -- in that case one needs to change the state of
one of the two bugs and then resubmit the merge directive.

Thanks.