Re: How does the Emacs bug tracker work?

[Stefan Monnier <monnier@iro.umontreal.ca>]

> So "closed" is mainly a way to say "I probably don't normally want to
> have these included in my searches".  So moving three year old
> "wontfix"-es over to "closed" means taking less time searching for the
> bugs you want to look at.

No, in my experience what I want to include in my searches depends a lot
on what I'm doing.  If I'm searching for duplicates, I want to include
pretty much all previous bugs no matter what, and if I'm looking for
"bugs that need love" I don't want to include any wontfix, regardless of
their age.
IOW, I don't find the notion of "closed" to be useful.

>> The bad ones are "untriaged", "forgotten" and "ready", so we should come
>> up with a way to distinguish inprogress from untriaged, as well as a way
>> to mark the forgotten ones as well, so we can ask debbugs to show us
>> these ones.
> If `date' is the same as `log-modified', it means that nobody has
> responded to the bug.  This can't be searched for, but can be
> highlighted in the debbugs buffer.

Rather than highlight, I'd like to see them sorted first, but yes, that
should be good enough.

>> I guess we could add "inprogress" and "forgotten" tags and then try to
>> be careful to add "inprogress" whenever we first reply to a bug report.
>> Then have some cron job check all the "inprogress" bugs and turn them
>> into "forgotten" after some pre-defined delay (at which point humans
>> way come and relabel it to "moreinfo" if the delay is not our fault).
> Adding these tags aren't really necessary if using the debbugs.el
> interface.   An "inprogress" report is one that has gotten at least one
> reply lately,

OK.

> and "forgotten" would be one where the reply is old.

OK (except if it's marked "moreinfo", of course).

> So this can be controlled client-side.  If you don't consider 30 seconds
> being too slow to get the complete list of bugs over to Emacs.

Sounds fine,


        Stefan