emacs-devel
[Top][All Lists]
Advanced

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

Re: Why Emacs needs a modern bug tracker


From: Óscar Fuentes
Subject: Re: Why Emacs needs a modern bug tracker
Date: Sat, 05 Jan 2008 20:05:42 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (windows-nt)

Eli Zaretskii <address@hidden> writes:

> Not just evidence: you should volunteer to do actual work.
[snip]

ESR volunteered for implementing the DVCS and the bug-tracker. I
volunteered for spam-filtering and monitoring the bug-tracker. I can do
other misc things, such as pre-testing the system and later assist other
users on its use.

> A bug tracker is a good case in point: Richard stated quite some time
> ago the basic requirements for his acceptance of such a tool, but no
> one stepped forward to do anything practical about that.

I'll be grateful if you direct me to the message where this requirements
were stated. I failed to find it on the archives.

>> For the bug tracker, I'm afraid it will not so easy. Most likely,
>> current Emacs developers should trade some diary personal incovenience
>> for some long-term project development efficiency. On the other hand, it
>> is difficult to appreciate the convenience of having an audit of a bug
>> or feature until you are using the system for some months.
>
> Starting such a system, but not making it mandatory, would be a good
> step towards the goal of having a good tracker in the future.  In
> general, a controversial feature should start as an option, before it
> becomes the default.

A bug tracker that is not updated by its users is worse than not having
a bug tracker. :-) Really, what is important is that bugs are entered on
the system. Users will do. You too, if you use report-emacs-bug. The
rest comes with little effort. Those who do not want web operation still
see the copy published on emacs-*-bugs (just as it happens today) and
can request from the system the equivalent of PROBLEMS and TODO with
simply a wget. You will not have files attached to the reports, such as
screenshots, but you have not them today either. Of course, you will be
allowed to request a single report intead of the full set of open
issues. When you fix something, just say in your commit message "Fixes
#1354" and the system will automatically close that bug (plus doing
other nice things). If you want to add a comment to a bug report, just
sending email to some emacs development mailing list mentioning its
number on the message subject would be enough. A sophisticated system
can inspect the body as well, so you can see in the bug report all
messages that ever mentioned it. No more black holes.

A bug tracker is a dynamic system in the sense that it can take
sophisticated actions in response to its input, and we can exploit this
on a variety of ways. A problem I perceive from the outside is that, for
a casual Emacs contributor, it is too hard to monitor mailing lists
looking for bug reports concerning the module(s) you maintain. The bug
tracker can associate an "owner" for every report. This owner is
determined either by the reporter's choice of affected module (say
cc-mode), or by some overseer that performs a superficial analysis of
the report (such person does not need to know a lot about Emacs
internals, an ignorant like me could do a decent job). The bug tracker
notifies the owner about the new bug and he can query the system for the
bugs assigned to him.

The advantages of a living database over a static text file are too
large to enumerate.

-- 
Oscar





reply via email to

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