Re: Why Emacs needs a modern bug tracker

[Alan Mackenzie]

Afternoon, Óscar!

On Sat, Jan 05, 2008 at 01:44:16AM +0100, Óscar Fuentes wrote:
> Alan Mackenzie <address@hidden> writes:

[ .... ]

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

Well....  Bug databases in companies tend to be done badly.  Some of the
forces that cause that might be present in free projects, so we need to
be very careful.

[ .... ]

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

I've never found a web browser good for anything other than browsing the
web.  I find filling in web forms so painful that I never do it unless I
can't avoid it.  Maybe getting the fields editable by Emacs would make it
tolerable.  We'll see.

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

Each of us have our own .emacs, some use a GUI, some text terminals, we
all use different mail clients, .....

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

Supremely important is that the new tools must be customizable to suit
the way ANY of us work.

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

Probably, so will I.

> Please keep an open mind.

I'm trying to be a counter-balancing force against those advocating
massive change.  

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

I've had nothing but bad experience using web interfaces for anything but
web browsing (in its narrow sense).  "Suffocatingly constrained"
accurately describes what I feel about these interfaces.  A good
comparison is that of Info documentation vs. the reading the same manual
as html.  I don't want to be forced to use a web interface, even a
keyboard driven one, for reporting bugs.  I can't be alone.

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

OK, VCS access IN ADDITION TO web access.  How about that?

> Furthermore, a bug-tracking system needs a database and a VCS is not
> good at that.

That is a good argument for staying with an email based system.  ;-(
What's the point of a bug system if you have to be online to use it?  It
kind of cancels out the benefit of a dVCS for our other files.

Are you telling me I won't be able to grep a bug-tracking database?  If
I'm using such a database, I want instant response when I press <CR> to
look at an item.  I want to be able to do M-x occur (or the like) on it,
without going through some ghastly GUI interface.  I want regexp
searching, filtering with a "command line"-like interface (e.g., like
mutt has), and so on.  And I want the database on my own hard disk, for
speed and flexibility.

> Oscar

-- 
Alan Mackenzie (Nuremberg, Germany).