bzr is dying; Emacs needs to move

[Eric S. Raymond]

I am posting this because I think it is my duty as a topic expert in
version-control systems and the surrounding tools to do so, not because
I have any desire to be in the argument that is certain to ensue.

The bzr version control system is dying; by most measures it is
already moribund.  The dev list has flatlined, most of Canonical's
in-house projects have abandoned bzr for git, and one of its senior
developers has written a remarkably candid assessment of why bzr
failed:

http://www.stationary-traveller.eu/pages/bzr-a-retrospective.html

I urge all Emacs developers to read this, then sleep on it, then read
it again - not least because I think Emacs development has fallen into
some of the same traps the author decribes.  But *that* is a discussion for
another day; the conversation we need to have now is about escaping
the gravitational pull of bzr's failure.

In theory, that failure need not affect us at all providing the bzr
codebase is sufficently mature to continue in use as a production
tool.  I judge that, in fact, it *is* sufficiently mature.

In practice, I judge that sticking with bzr would have social and
signaling effects damaging to Emacs's prospects. Sticking to a 
moribund version-control system will compound and exacerbate the 
project's difficulty in attracting new talent.

The uncomfortable truth is that many younger hackers already think
Emacs is a dinosaur - difficult, bulky, armor-plated, and generally
stuck in the last century. If we're going to fight off that image, we
cannot afford to make or adhere to choices that further cast the
project as crusty, insular, and backward-looking.

As of right about now, continuing with bzr is such a choice.  We'll
lose potential recruits, not merely because bzr has a learning cost
but because crusty, insular, etc.  The opportunity cost of not getting
out will only rise with time.

git won the mindshare war.  I regret this - I would have preferred
Mercurial, but it too is not looking real healthy these days.  I have
made my peace with git's victory and switched.  I urge the Emacs
project to do likewise.

I can be technical lead on the migration - as the author of
reposurgeon I have the skills and experience for that (I recently
moved GNU troff from CVS to git). But the project leadership needs
to make the go decision first.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

No one who's seen it in action can say the phrase "government help" without
either laughing or crying.