Re: Bug tracking

[Juanma Barranquero <lektu@mi.madritel.es>]

On Sat, 12 Jun 2004 18:38:29 +0300, Juri Linkov <juri@jurta.org> wrote:

> Even without special mode a plain text file is the most convenient
> way to edit data and to perform arbitrary Emacs operations on them.

No, a plain text file is not necessarily "the most convenient way to
edit data", not by a long shot. Certain kinds of data, yes.  And yes, it
is easi to perform arbitrary Emacs operations on it, but we don't want
to perform arbitrary operations, but a few, very specific, widely used
kinds of operations: the ones usually associated with bug/issue
management.  Your claim is so broad that it seems like you were saying
that Emacs is "the most convenient way" to do anything.

> I think there is nothing wrong with the fact that only Emacs
> developers will be able to fill bug reports.  So no web interface
> is really needed.

Obviously, we *strongly* disagree here.  I see much wrong with only
Emacs developers being able to fill bug reports (for one, that means
someone *has* to do the work which could have made the user).  So the
web interface is, to me, really needed.

> That's exactly how it might work: developers read gnu-emacs-bugs,
> create new bug entries in the text file and commit them to CVS.
> And you can track changes in the text file with all the usual
> features of CVS.

Yes, I understand how could it work, I just happen to think that is a
extraordinarily un-optimized way to do things.  See etc/TODO: would you
dare say that it is really used for the intended purpose?  Many things
in TODO have been there for years, and almost *all* things implemented
or fixed never ever touched TODO.

> Apart from the Ee categorizing manager, I think that some other
> Emacs packages can perform these operations on text files.
> AFAIK, at least Gnus should be able to read a text file in the
> mail-like format and to treat it as a mail group with bug and TODO
> entries as messages.  There are even many possibilities of tighter
> integration with its email functionality.

Aren't you saying that we can shoehorn something into simulating being an
issue tracker, just to *not* use an issue tracker which already does all
that?


                                                           /L/e/k/t/u