Re: Why Emacs needs a modern bug tracker

[Gianluca Della Vedova]

Andreas Röhler <andreas.roehler <at> online.de> writes:

> 
> Am Freitag, 4. Januar 2008 17:44 schrieb Eric S. Raymond:
> 
[ stuff deleted ]
> >
> > One of the places a real issue database is most concretely useful is when
> > you're triaging bugs to close on a release.  It is *immensely* helpful
> > in making clear what needs to be done and at what point you are
> > finished doing it.
> >
[ stuff deleted ]

> > Beside the searchability problems with pile-of-emails organization
> > is another one; accepting emailed reports makes even *collecting*
> > well-structured information about bugs highly problematic.
> >
> > The good thing about bug-tracker web forms from a developer point of
> > view isn't really that they're web, it's that they're *forms*. You can
> > channel your users into identifying the platform they're running on,
> > the preceived bug severity, and half a dozen other search keys.
> >
> > In email, users will embed these things in running text and expect
> > you to parse them by eyeball.  Which means if you want a database
> > of bug reports instead of a mere pile of them, you get to re-enter
> > each one.  Yuck.  In practice, nobody is ever willing to do this.
> >
> > This means that email bug entry needs to be deprecated, redirecting
> > people to a web form (or, in the special case of Emacs, a simulated
> > form in emacsbug).  Had you not wondered why Emacs is about the only
> > major project left that *isn't* trying to push its users onto an issue
> > tracker?  This is why...
> >
> > To sum up the back-end argument, the reason I want Emacs to have a
> > real bug tracker is for the database it will build, so we'll have a
> > better view of our bugs.  From this (developer) point of view it's
> > accidental rather than essential that the all the good ones built in
> > the last decade are Web-facing.
> >
> > Now let's talk about user experience.
> >
> > *This* is where browser-centric interfaces become important.  I
> > know from recent experience on Wesnoth and elsewhere that most users
> > actually prefer using a well-designed web-based bug tracker to
> > emailing bug reports.  For them, it *is* about the browser UI.  They
> > find the structure and the sense of familiarity reassuring.
> >
> > Gianluca makes exactly this point in his post.

Almost my point.
I agree that, IMO, the browser UI is better then email for bug submissions.
But I was also referring to the fact emails can get replies that are quite
discomforting, if not nasty or rude: Such a kind of response can quickly lead to
abandon the mailing list. 

A web form is perceived to be more anonymous, and closing a "fake" bug report
without explanation (because it is not really a bug) is not something that can
be taken personally. I don't think the same applies to emails to a mailing list,
where the fact that a bug report is bogus is exposed to everybody.

Part of my post was also devoted to give some of the benefits of the issue
database structure that Eric has clearly described above.

[ stuff deleted ]

> > Fortunately, most modern issue trackers allow you to feed all the
> > submissions and followon comments to a designated buglist.  So, if and
> > when we activate one, you old-schoolers will be able to keep your Gnus
> > readers.
> 

In my blog post (and not in my previous email) I suggested a bug tracker similar
to Debian's. It's main advantage, among other bug tracker I know of, is that it
can be effectively used by email only.

Tipically a bug report is filled on the web (as Eric has suggest it can be
emulated via a Emacs form). For each bug report a unique email address is
created, and the bug report, as well as any subsequent comments is sent also to
such address. The same address can also be used for sending commands for
handling the bug: such commands can be something like "close the bug", or "set
severity to ..".

Since reporting a bug is usually done by a user and not by a developer, I
believe that such a bug tracker could easily fit with the current developers'
modus operandi.

[ stuff deleted ]

> 
> With Richard, principles of developing are more or less
> immanent by his decisions and experience. 
> To keep this waste universe of code running smoothly
>  will afterwards need a lot more of
> outspoken rules than now.
> 

If Emacs is adopting a bug tracker some new rules (i.e. what are the possibile
severity levels) are necessary. 

> Concerning the bugtracking: a lot of bugs reported
> aren't really one. That can't be changed. What with all
> this false bugs in a database?
> 

They can be closed clicking on a button or sending an email with subject
"closed". The effort should not be that much than ignoring the email after
having read it.

> OTOH some severe bugs seem reported from time to time,
> but not fixed so far. Will a database change that?
> 
No.

But some less severe bugs can be fixed by non-core developers, giving more time
for the core developers to work on more important issues.

And the number/quality of users confirming a bug can help in understanding the
actual severity of the bug.


> What about some kind of a blackboard, establishing a
> hierarchy of important bugs naming a person in charge
> for it?
> 

It is one of the purposes on having an issue tracker.