emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How does the Emacs bug tracker work?


From: Stefan Monnier
Subject: Re: How does the Emacs bug tracker work?
Date: Thu, 30 Jun 2011 15:56:35 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

>>> What about Wontfix bugs? Shouldn't we close these?
>> Usually they're good and valuable as documentation.
> Closed bugs are still there if you want to look at them.

I see bugs as being in a few different states:
- untriaged: we got the report and nothing else happened.
- inprogress: there's been at least one reply to it.
- stuck: like inprogress, but without activity because of lack of info.
- forgotten: like stuck, except that rather than a lack of info, there's
  a lack of manpower.
- ready: there's a patch that fixes the problem and it looks like we
  just have to double-check and/or cleanup the patch.
- fixed: that's what we like.
- wontfix: we don't think it's a bug, or we don't like the requested
  feature and would hence oppose a patch if someone provides it.
- wishlist: not a bad idea, but noone cares enough to work on it.

These states map more or less to debbugs tags/severities:
- untriaged = "unclassified"
- inprogress = ???
- stuck = "moreinfo"
- forgotten = ???
- ready = "patch"
- fixed = "fixed" or "closed"
- wontfix = "notabug" or "wontfix"
- wishlist = "wishlist"

I don't really know what "closed" should mean in this respect and don't
really care as long as I can easily select which above states I want
to see.
And I don't understand why Debbugs has "wishlist" as a severity rather
than a tag (which prevents us from distinguishing important wishes from
minor ones).

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.

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



        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]