Re: Why Emacs needs a modern bug tracker

[Óscar Fuentes]

Alan Mackenzie <address@hidden> writes:

[snip]

>> Only...I suspect you (the team) don't know how poor your view is,
>> because you've never had a good view of a bug collection at your scale
>> to contrast it with.  (To be fair, it's only in the last two or three
>> years that I have grasped this myself.)
>
> I've worked many years in industry.  Bug databases done badly are worse,
> much worse, than our email archive.

X done badly is worse than not having X... this is a general
justification for rejecting change, not for rejecting bad ideas.

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

The usual spam-detection schemes works for bug submissions and every
serious bug-tracking system supports them. There is no reason for having
more spam on the bug tracker than on this same mailing list. For the
required human intervention, I volunteer.

[snip]

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

Most fields are automatically filled by Emacs.

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

Sure, this is what we can expect from Emacs' corporate culture
<g>. Please be serious. There are no pointy-haired bosses here.

[snip]

>> 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.
>
> Right.  Eric, unplug your mouse and tell me how well-designed and
> reassuringly familiar it is then.  I'm required to drive a bug database
> (and other process abortions) by a grotty point and click web interface 8
> hours per working day at my day job, and I'm damned if I'm going to come
> home and spend my playing time doing the same.
[snip]

I don't use point-and-click for filling web forms, keyboard works fine,
thanks. See available solutions for your web browser. Even for filling
text areas I use an utility that makes possible and convenient to do it
with my favourite text editor.

Really, it not as bad as you paint it, once you (and not your
pointy-haired boss) are the one that controls the tools.

> Like Richard said in another thread, we all have different proclivities,
> and we _CHOOSE_ our tools to suit us.

If we all have different proclivities, why we all use the same tools for
developing Emacs? I guess this is because of consensus. You use CVS,
although others may prefer Arch, and so on. The issue here is: are there
better options? something that enhances our *overall* sense of
gratification?  See, DVCSs are great for working off-line, plus lots of
other major advantages over CVS. However, the proposal had a cold
response by precisely those who valuates working offline as
essential. After reading RMS' replies I'm sure that if he works with a
decent DVCS for a month, he will reject going back to CVS. Seriously.

Please keep an open mind.

> By the very nature of our product, we care deeply about the tools we
> use.  Perhaps this is the real reason Emacs is still using email for
> dealing with bugs, rather than a bug tracker with a suffocatingly
> constrained web interface.

Expressions like "suffocatingly constrained web interface" are too
negative. Maybe you had a bad experience. I only can say that I wish
Emacs' Customize forms were more web-form-alike.

[snip]

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

I was thinking about this possibility and concluded that it is not
possible to build a decent bug-tracking system using only a VCS. The
reason is the importance of the user interface, which must be open to
everybody, not only for the committers, as PROBLEMS and TODO are now,
thus effectively dissuading possible contributions from the
outside. Furthermore, a bug-tracking system needs a database and a VCS
is not good at that.

-- 
Oscar