Re: Why Emacs needs a modern bug tracker

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 5 Jan 2008 13:24:56 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: "Eric S. Raymond" <esr@snark.thyrsus.com>, emacs-devel@gnu.org
> 
> First, the size of a project's bug load is driven by the square of
> LOC.  This is because most bugs are clashes between assumptions mode
> in differing parts of the code.

You are assuming that all parts of the code are being developed, it
seems.  That's not what happens in Emacs, probably due to its age and
the fact that core features are developed/refactored only very seldom,
or not at all.

In any case, unless we lose a huge amount of bugs due to lack of
tracking, the amount of bugs in Emacs is not consistent with the
quadratic curve hypothesis, let alone higher powers.  And the bugs
reported through the various Emacs channels do not suggest that we
leave such a large amount of bugs without fixing, or else we'd have
lots of repeated bug reports.

> > In Emacs development, we have problems to even find a release manager,
> > let alone someone who will replace Richard as a head maintainer.  So
> > having a bug triage system that is significantly better that a flat
> > text file such as admin/FOR-RELEASE is not necessarily the first
> > priority here.
> 
> Perhaps not.  But it certainly couldn't hurt.

``Couldn't hurt'' is not a good argument when deciding where to apply
limited resources.  Like in code optimization, you first try to
identify the hot spots, and then go for those spots first.

But as I said elsewhere, let's have a bug tracker happen, and see
where it gets us.  I have seen enough talking on this issue; if
there's energy left in those who think a bug tracker will make a
difference, let's see it in action and argue later.

> And, maybe, if bug-triage weren't quite so much like having a herd
> of elephants stampede over your testicles, a release manager might
> be just a *leetle* easier to find?

You are certainly not stupid enough to believe I'm talking
theoretically here.  I actually was an Emacs release manager once, and
I don't recall having any special problems managing the bug queue,
certainly not something that could be described as elephants stampede
over my testicles.

What took most of the time during the release is _fixing_ the bugs,
not tracking them.

If your scaling assumptions are true, I don't see how they can be
supported by my own experience of participation in Emacs maintenance.