From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: esr@thyrsus.com (Eric S. Raymond) Newsgroups: gmane.emacs.devel Subject: bzr is dying; Emacs needs to move Date: Thu, 2 Jan 2014 04:53:47 -0500 (EST) Message-ID: <20140102095347.6834E381D0C@snark.thyrsus.com> NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1388656431 17507 80.91.229.3 (2 Jan 2014 09:53:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Jan 2014 09:53:51 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 02 10:53:59 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VyeyV-0005Do-IR for ged-emacs-devel@m.gmane.org; Thu, 02 Jan 2014 10:53:59 +0100 Original-Received: from localhost ([::1]:44133 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VyeyV-0001lg-3i for ged-emacs-devel@m.gmane.org; Thu, 02 Jan 2014 04:53:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VyeyO-0001lO-Hb for emacs-devel@gnu.org; Thu, 02 Jan 2014 04:53:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VyeyK-0008MQ-88 for emacs-devel@gnu.org; Thu, 02 Jan 2014 04:53:52 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:57464 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VyeyK-0008MG-3a for emacs-devel@gnu.org; Thu, 02 Jan 2014 04:53:48 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 6834E381D0C; Thu, 2 Jan 2014 04:53:47 -0500 (EST) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 71.162.243.5 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:167023 Archived-At: 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. -- Eric S. Raymond No one who's seen it in action can say the phrase "government help" without either laughing or crying.