Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

This is the actual metadata available on a bug:

(pp (debbugs-get-status 5458) (current-buffer))
(((source . "unknown")
  (done . "Lars Magne Ingebrigtsen <larsi@gnus.org>")
  (found_versions)
  (blocks)
  (date . 1264225022)
  (fixed)
  (fixed_versions)
  (mergedwith)
  (found)
  (unarchived)
  (blockedby)
  (keywords "moreinfo")
  (summary)
  (msgid . "<871vhh7588.fsf@jidanni.org>")
  (id . 5458)
  (forwarded)
  (severity . "normal")
  (owner)
  (log_modified . 1309402441)
  (location . "db-h")
  (subject . "Unknown charset: ansi_x3.4-1968")
  (originator . "jidanni@jidanni.org")
  (last_modified . 1309402441)
  (pending . "done")
  (affects)
  (archived)
  (tags "moreinfo")
  (fixed_date)
  (package "emacs" "gnus")
  (found_date)
  (bug_num . 5458)))

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

The relevant stuff we can search for are package, severity and tag (and
"archived", which is where I think "done" bugs up end after some days).

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.

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

> 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, and "forgotten" would be one where the reply is old.

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.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/