Re: Why Emacs needs a modern bug tracker

[Eli Zaretskii]

> From: "Eric S. Raymond" <address@hidden>
> Date: Fri,  4 Jan 2008 11:44:54 -0500 (EST)
> 
> The difference is scale.  GPSD is about 60K lines of code, with a
> COCOMO estimate of about 14.2 person-years and about 3 active
> developers; normally we only have three or four issues active at once.
> Wesnoth is a hair over 100K lines, with a COCOMO estimate of 25.6
> years and 10-12 active developers; over the last year we've gone from
> about 500 issues tracked to a bit over 300 (currently 196 feature requests,
> 89 bugs, and the remainder marked Fixed but not yet purged).
> 
> Somewhere in the scale range between GPSD and Wesnoth, having an issue
> tracker moves from being a dispensable luxury to being an extremely
> important tool. [...]
> 
> Now I consider Emacs: 1100K lines, a COCOMO estimate of over 328
> years, and no issue database. I think I think I understand much better
> now 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.

You are implicitly assuming here that what is good for a COCOMO-25
project and 10-12 active developers should be also good for a
COCOMO-328 project with fewer than 10 developers.  Do you have any
evidence that this assumption is true, or arguments that would tell me
such an assumption is reasonable?

> One of the places a real issue database is most concretely useful is when
> you're triaging bugs to close on a release.  It is *immensely* helpful
> in making clear what needs to be done and at what point you are
> finished doing it.

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.

Emacs is HUGE.  Its immense size is not the only problem: there are
many parts in it that require experts in specific areas (GUI display,
networking, Lisp infrastructure, email, multilingual text editing, to
name just a random few) in order to know what is right and wrong when
reviewing patches.  Just figuring out how best to organize maintenance
of such a large package is a daunting task, to say nothing of actually
implementing such a maintenance scheme (which would mean finding and
recruiting individuals who could become part of such a team, then
making a coherent and cooperative team out of them).  It is IMO naive
at best to think that switching to more collaborative tools would
somehow magically solve these _real_ problems, or even pave a way for
their _practical_ solution.