[Top][All Lists]

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

Re: Why Emacs needs a modern bug tracker

From: Alan Mackenzie
Subject: Re: Why Emacs needs a modern bug tracker
Date: Sat, 5 Jan 2008 11:17:20 +0000
User-agent: Mutt/1.5.9i

Hi, Eric!

On Sat, Jan 05, 2008 at 12:20:07AM -0500, Eric S. Raymond wrote:
> Alan Mackenzie <address@hidden>:

[ .... ]

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

OK, we're agreed!  There was something in your posting which suggested
the notion that merely using such tools would be the Right Thing.  We
need to use them well, too.

[ .... ]

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

What is "emacs-bug"?  I think I'm missing some context somewhere.

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

The best (proprietary) bug tracker I ever used had fields only for things
like person creating the entry, status (open/fixed/rejected), customer,
severity, urgency.  Then it had free text areas for describing the bug.

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

Deprecated or enhanced?  ;-)

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

Fair response.  ;-)  But the base system has to be one that allows
appropriate access.  A mail archive allows searching by all of mutt's
handy operators.  You can even grep the raw mailbox archive (yes, this IS
useful, even though you only need to do this occasionally).  My fear is
that the new bug tracker will be restricted to what its designers thought
was "all that you need"; or that I'll have to go through a ghastly point
and click "create a query" interface, like I had to yesterday at work.

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

I wasn't very clear, there.  Of course users need web forms, and they
will manipulate the database directly.  But why can't we have VCS
updating, too?  This will allow RMS and others to work offline, a very
desirable thing.

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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