Re: Why Emacs needs a modern bug tracker

[Eric S. Raymond]

Alan Mackenzie <address@hidden>:
>       I think RMS can and does keep well abreast of the bug status,
> even though I wouldn't be able to with just email.

Maybe you're right.  But (a) RMS isn't going to do that job forever,
and (b) even he were eternally available, the project has better uses
for his brain than the donkey-work of carrying around all that issue
state.  I for one would rather see that energy spent on creation.

> I don't think we want to do several major releases per year.

I don't think we do either,  But several minor releases would be 
a good idea, if only to counter the widespread perception that the
project is sclerotic.

> I've worked many years in industry.  Bug databases done badly are worse,
> much worse, than our email archive.

Granted.  But we have the talent and tools to do it right.
 
> Talking of which: however we collect bug reports, we will need moderation
> of some sort to exclude spam.  Can we take it that this is a solved
> problem?

I've never seen spam on the Wesnoth bugtracker.  It does include a feature
that allows the first responder on a bug to flag it as spam.  I presume
it is then excluded from the normal view.

If emacs-bugs doesn't already have a spam problem, a tracker isn't 
likely to either.

> If they're pure web, I doubt they'll be accepted by the hackers here,
> who're accustomed to Emacs-quality interfaces.  Whatever we decide on
> must be usable from a normal Emacs buffer.

There's emacs-bug to be hacked.  And one of our listmembers has
already noted that the Debian tracker can be driven by email.

> Also, the fields in these forms must be kept under as tight control as a
> camp fire in a drought stricken forest.  4 or 5 fields are OK.  8 to 10
> are pushing the boundary.  Let a QA department into the works, and before
> you know it you've got upwards of 100 largely meaningless fields, so that
> said QA "can accurately monitor the trends and problems of the developers
> and tune the company's processes accordingly".

This is true.  You'll be reassured, perhaps, to know that the
evolutionary direction in bug trackers has been to simplify, simplify,
simplify.  The original Bugzilla was exactly the sort of nightmare you
describe, and I refused to have anything to do with it.  More recent
ones like the Ubuntu and Gna! bug trackers are quite lightweight 
and pleasant by comparison.

> I disagree.  An email bug entry system is necessary, and should perhaps
> be the preferred method, with a web form as an alternative.  This email
> will of course be structured.  M-x report-emacs-bug or C-c C-b (in a CC
> Mode buffer) could be enhanced easily enough.

Like I said, emacs-bug.  It's *unstructured* mail that has to be
deprecated.
 
> Hmmm.  I hope that's not as contumelious as it sounds.  That "allow" had 
> better be a first class interface, not just a second rate crock intended
> to keep us "outmoded grandads" from moaning.

Write it.  Then you'll know it's correct.

> How about this suggestion: the bug database should be administered by our
> super-duper new distributed VCS, having its definitive version at
> savannah.  Hackers will then update it by committing (?pushing) their
> changes from their own local versions.  With these local versions, they
> will have far more usable and flexible facilities than they would over a
> lame http connection.

No good.  You're ignoring the *users*.  Remember users...you know, he people
the reporting emd of a tracker is actually *for*?  They don't want to futz with 
some geek's wet dream of "flexibilty".  They want web forms.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>