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 inversion-control systems and the surrounding tools to do so, not becauseI have any desire to be in the argument that is certain to ensue.The bzr version control system is dying; by most measures it isalready moribund. The dev list has flatlined, most of Canonical'sin-house projects have abandoned bzr for git, and one of its seniordevelopers has written a remarkably candid assessment of why bzrfailed:I urge all Emacs developers to read this, then sleep on it, then readit again - not least because I think Emacs development has fallen intosome of the same traps the author decribes. But *that* is a discussion foranother day; the conversation we need to have now is about escapingthe gravitational pull of bzr's failure.In theory, that failure need not affect us at all providing the bzrcodebase is sufficently mature to continue in use as a productiontool. I judge that, in fact, it *is* sufficiently mature.In practice, I judge that sticking with bzr would have social andsignaling effects damaging to Emacs's prospects. Sticking to amoribund version-control system will compound and exacerbate theproject's difficulty in attracting new talent.The uncomfortable truth is that many younger hackers already thinkEmacs is a dinosaur - difficult, bulky, armor-plated, and generallystuck in the last century. If we're going to fight off that image, wecannot afford to make or adhere to choices that further cast theproject as crusty, insular, and backward-looking.As of right about now, continuing with bzr is such a choice. We'lllose potential recruits, not merely because bzr has a learning costbut because crusty, insular, etc. The opportunity cost of not gettingout will only rise with time.git won the mindshare war. I regret this - I would have preferredMercurial, but it too is not looking real healthy these days. I havemade my peace with git's victory and switched. I urge the Emacsproject to do likewise.I can be technical lead on the migration - as the author ofreposurgeon I have the skills and experience for that (I recentlymoved GNU troff from CVS to git). But the project leadership needsto 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" withouteither laughing or crying.