Re: Bug tracking

[Richard Stallman]

    > We're not planning to use this to track individual bugs,

    Why not?  I thought the discussion was about putting things reported
    by M-x report-emacs-bug RET into a database?

No, this discussion is about tracking issues that need to be
resolved before the release.  Here is the message that raised this
question:

    Still, the question remains: should we use some kind of issue tracker?

    Currently we have an etc/TODO, which is sort of half wish list, half
    grab bag of heterogeneous items.  I'm all for using an issue tracker, if
    only because it makes easier to know where we are, release-wise, for any
    given release.  For example, what's precluding us from doing a
    prerelease tarball just today (not that I'm proposing it, of course)?

The answer to this question is not a list of bug reports; this job is
not bug tracking.

Tracking issues cannot mean bug tracking, because only something
important qualifies as an "issue".  A mere bug report is not (usually)
an issue.  On some occasions a certain bug report might be important
enough to be an issue, but only the Emacs developers can decide when
that is so.  Only the developers can enter issues, and it makes no
sense to have a large number of issues.

A text file is the perfect way to keep track of issues.

Bug tracking might be useful, but it is a completely different
subject.  If we use a bug-tracker, it should be easy to use via email
and cvs.