bzr is dying; Emacs needs to move

From: Eric S. Raymond Subject: bzr is dying; Emacs needs to move Date: Thu, 2 Jan 2014 04:53:47 -0500 (EST)

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.

reply via email to

