Re: bzr is dying; Emacs needs to move

[David Reitter <david.reitter@gmail.com>]

In support of the proposal:

1. Yes, please switch to git.

2. I am someone who had commit access in CVS days, but stopped making my small contributions when bzr was introduced, following extensive tries to adopt bzr for Aquamacs or to use it for small, infrequent contributions.  It didn't seem worth the effort.

3. Please use the official mirror as a basis.  It's a good mirror.  Anything else would be a PITA for downstream developers and anyone who maintains a separate git branch of Emacs.   After 50 merges from the mainline and >4500 commits, rebasing to preserve history seems like a big deal.

4. The Changelog files are a frequent cause of conflicts.  "git log --grep=" is fast.  What is the use?


On Jan 2, 2014, at 4:53 AM, Eric S. Raymond <esr@thyrsus.com> 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
> 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.
>