Re: Why Emacs needs a modern bug tracker

[Alan Mackenzie]

Hi, Eric!

On Fri, Jan 04, 2008 at 11:44:54AM -0500, Eric S. Raymond wrote:

[ .... ]

> Now I consider Emacs: 1100K lines, a COCOMO estimate of over 328 years,
> and no issue database. I think I understand much better now why the
> team has only been able to ship one release in five years.  Trying to
> converge on a releasable state with as poor a view of the Emacs bug
> load as we have must be damn near impossible.

I think you've got a case, but you're overstating it.  Each (major) Emacs
release goes through exhaustive testing, and this takes many, many
months.  I think RMS can and does keep well abreast of the bug status,
even though I wouldn't be able to with just email.

I don't think we want to do several major releases per year.  Perhaps
once every two years.  Upgrading, for typical users, is nerve-wracking,
and costs time and energy.  They want to do it as little as possible, or
never.  For industrial programmers who are behind schedule (i.e. all of
them), they need a strong reasons before they will upgrade.

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

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

If they're pure web, I doubt they'll be accepted by the hackers here,
who're accustomed to Emacs-quality interfaces.  Whatever we decide on
must be usable from a normal Emacs buffer.

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

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

I disagree.  An email bug entry system is necessary, and should perhaps
be the preferred method, with a web form as an alternative.  This email
will of course be structured.  M-x report-emacs-bug or C-c C-b (in a CC
Mode buffer) could be enhanced easily enough.

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

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.  Discarding spam from a
mailman moderation web interface (which I do for help-gnu-emacs and
bug-gnu-emacs) is about as far as I want to go with point and click, and
even that's only tolerable because it's so mindless.

Like Richard said in another thread, we all have different proclivities,
and we _CHOOSE_ our tools to suit us.  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.

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

Hmmm.  I hope that's not as contumelious as it sounds.  That "allow" had 
better be a first class interface, not just a second rate crock intended
to keep us "outmoded grandads" from moaning.

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.

-- 
Alan Mackenzie (Nuremberg, Germany).