From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bozhidar Batsov Newsgroups: gmane.emacs.devel Subject: Re: bzr is dying; Emacs needs to move Date: Thu, 2 Jan 2014 14:30:31 +0200 Message-ID: References: <20140102095347.6834E381D0C@snark.thyrsus.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="52c55be7_338125cf_1c26" X-Trace: ger.gmane.org 1388665840 18454 80.91.229.3 (2 Jan 2014 12:30:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Jan 2014 12:30:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Eric S. Raymond" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 02 13:30:48 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 1VyhQF-0001yQ-L7 for ged-emacs-devel@m.gmane.org; Thu, 02 Jan 2014 13:30:47 +0100 Original-Received: from localhost ([::1]:44627 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VyhQE-0006IO-RO for ged-emacs-devel@m.gmane.org; Thu, 02 Jan 2014 07:30:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41716) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VyhQ9-0006IG-LK for emacs-devel@gnu.org; Thu, 02 Jan 2014 07:30:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VyhQ5-0006Fk-8U for emacs-devel@gnu.org; Thu, 02 Jan 2014 07:30:41 -0500 Original-Received: from mail-ee0-x22d.google.com ([2a00:1450:4013:c00::22d]:61964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VyhQ4-0006FT-Rl for emacs-devel@gnu.org; Thu, 02 Jan 2014 07:30:37 -0500 Original-Received: by mail-ee0-f45.google.com with SMTP id d49so6112889eek.18 for ; Thu, 02 Jan 2014 04:30:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=2UJAgq1uMsLzf4NA9Xilk/giYO6hnUohM23etk5ZR+8=; b=WvMWen2BxuEsChQ4p5YhzJDi84XiV7sUC+nuxTsuZLNkxyFey6WZXAPExkEuatA+VE dLTfkmMfoBwQu3YaX/kJGq009uJspdWqMhyEMBXxL10B4k5MCdO0fyn4WcB7+5GkLrUs VzofAMO2LSgE8F7kUhjfmnbpAg3Rl+B4LoHpf2glvhPJf2kkXEKCgl0pbNnpxBTAyM6N xjoDC/ByieXD6drZx6i2pJCnzzIW6ayR/ZZasEUdgDSKbKxq9mrRya4km6nyq0EuvOpC xsf/cfm85fqlVp/6rKO+mlVpX6LccbLoEfzRwf7ujl+GCPKBLB43OvcaFxHb6/qvrWkW s66A== X-Received: by 10.15.26.6 with SMTP id m6mr15353480eeu.80.1388665835966; Thu, 02 Jan 2014 04:30:35 -0800 (PST) Original-Received: from [10.0.1.8] (93-152-182-45.ddns.onlinedirect.bg. [93.152.182.45]) by mx.google.com with ESMTPSA id z42sm135644804eeo.17.2014.01.02.04.30.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 02 Jan 2014 04:30:35 -0800 (PST) In-Reply-To: <20140102095347.6834E381D0C@snark.thyrsus.com> X-Mailer: sparrow 1.6.4 (build 1178) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::22d 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:167027 Archived-At: --52c55be7_338125cf_1c26 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I agree with most of the points you make and I=E2=80=99d love for Emacs t= o adopt git, but judging from the last discussion on the topic a few mont= hs ago (http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00776.ht= ml), I don=E2=80=99t think that=E2=80=99s going to happen any time soon. Btw, Richard said then he wanted to give bzr=E2=80=99s maintainer a reaso= nable amount of time to fix some bugs (or so I recall). If this hasn=E2=80= =99t happened - there=E2=80=99s one more argument in favour of using git.= Relying on a poorly maintained project is generally worse than relying o= n a unpopular project. =20 -- =20 Cheers, Bozhidar 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. > =20 > 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: > =20 > http://www.stationary-traveller.eu/pages/bzr-a-retrospective.html > =20 > 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. > =20 > 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. > =20 > In practice, I judge that sticking with bzr would have social and > signaling effects damaging to Emacs's prospects. Sticking to a =20 > moribund version-control system will compound and exacerbate the =20 > project's difficulty in attracting new talent. > =20 > 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. > =20 > 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. > =20 > 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. > =20 > 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. > -- =20 > Eric S. Raymond > =20 > No one who's seen it in action can say the phrase =22government help=22= without > either laughing or crying. > =20 > =20 --52c55be7_338125cf_1c26 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I ag= ree with most of the points you make and I=E2=80=99d love for Emacs to ad= opt git, but judging from the last discussion on the topic a few months a= go (http://lists.gnu.org/archive/html/emacs-devel/2013-03/ms= g00776.html), I don=E2= =80=99t think that=E2=80=99s going to happen any time soon.

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

-- 
Cheers,
=
Bozhidar

=20

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

I am posting this because I thin= k it is my duty as a topic expert in
version-control systems an= d 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 b= zr
failed:


<= div>I urge all Emacs developers to read this, then sleep on it, then read=
it again - not least because I think Emacs development has fal= len 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 fail= ure.

In theory, that failure need not affect us = at all providing the bzr
codebase is sufficently mature to cont= inue in use as a production
tool. I judge that, in fact, it *i= s* sufficiently mature.

In practice, I judge tha= t sticking with bzr would have social and
signaling effects dam= aging to Emacs's prospects. Sticking to a
moribund version-con= trol system will compound and exacerbate the
project's difficu= lty in attracting new talent.

The uncomfortable = truth is that many younger hackers already think
Emacs is a din= osaur - difficult, bulky, armor-plated, and generally
stuck in = the last century. If we're going to fight off that image, we
ca= nnot 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 cos= t
but because crusty, insular, etc. The opportunity cost of no= t 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 ha= ve
made my peace with git's victory and switched. I urge the E= macs
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 ma= ke the go decision first.
--
<a href=3D=22http://www.catb.org/=7Eesr/=22= >Eric S. Raymond</a>

No one who's seen = it in action can say the phrase =22government help=22 without
e= ither laughing or crying.
 =20 =20 =20 =20
=20

--52c55be7_338125cf_1c26--