[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bzr is dying; Emacs needs to move

From: Bozhidar Batsov
Subject: Re: bzr is dying; Emacs needs to move
Date: Thu, 2 Jan 2014 14:30:31 +0200

I agree with most of the points you make and I’d love for Emacs to adopt git, but judging from the last discussion on the topic a few months ago (http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00776.html), I don’t think that’s going to happen any time soon.

Btw, Richard said then he wanted to give bzr’s maintainer a reasonable amount of time to fix some bugs (or so I recall). If this hasn’t happened - there’s one more argument in favour of using git. Relying on a poorly maintained project is generally worse than relying on a unpopular project.


On Thursday, January 2, 2014 at 11:53 AM, Eric S. Raymond wrote:

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


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

[Prev in Thread] Current Thread [Next in Thread]