From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: On the subject of Git, Bazaar, and the future of Emacs development Date: Thu, 28 Mar 2013 16:10:38 -0500 Message-ID: <87k3orw7qp.fsf@kwarm.red-bean.com> References: <87hajxqlly.fsf@yandex.ru> Reply-To: Karl Fogel NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1364505057 24771 80.91.229.3 (28 Mar 2013 21:10:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Mar 2013 21:10:57 +0000 (UTC) Cc: lekktu@gmail.com, emacs-devel@gnu.org, John Yates To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 28 22:11:24 2013 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 1ULK6T-0000Oy-JR for ged-emacs-devel@m.gmane.org; Thu, 28 Mar 2013 22:11:21 +0100 Original-Received: from localhost ([::1]:60316 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULK64-00079E-Rc for ged-emacs-devel@m.gmane.org; Thu, 28 Mar 2013 17:10:56 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48328) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULK5s-000792-UK for emacs-devel@gnu.org; Thu, 28 Mar 2013 17:10:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ULK5p-0007Fx-Pe for emacs-devel@gnu.org; Thu, 28 Mar 2013 17:10:44 -0400 Original-Received: from mail-ie0-x233.google.com ([2607:f8b0:4001:c03::233]:37290) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULK5p-0007Fr-Jh; Thu, 28 Mar 2013 17:10:41 -0400 Original-Received: by mail-ie0-f179.google.com with SMTP id k11so12050080iea.38 for ; Thu, 28 Mar 2013 14:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:from:to:cc:subject:references:reply-to:date :in-reply-to:message-id:user-agent:mime-version:content-type; bh=jiljhmoe7XhmlGoV3Edw/w8PaEfX8VhTMtshHZx4KZ0=; b=YZYQ6p4Aha7wzJh+sj/tayJgtP08CvrDi1Mof88T1PKQao81Bo12ER7sbZNWJzfAbz WQF/H/Zdw+5pSdGV9BIsAFirVvp1Jpb09gd/yF/I/gL4za0U49mxlnqv7VUbmRgaXfV2 lWGeM0UOyBAdkfIsyRpYV+6Tw0dKDOiMc7hEtRk1s2vFk5aXUatCsBLN/vrt5meL0eL7 S11j11TyVQXUPVNr8wJDgK36CqXNpFOiSvjDBcw3zB32Uo2DV+Qe0Wk/56WND62TS3P1 OwtPHKaWLPAD3gCrFUXTcmNcFNSUoOQ7unj+owXB6okDbpGCce3Xc1eKL60hGYK7uN8s AKIg== X-Received: by 10.50.20.135 with SMTP id n7mr8008123ige.31.1364505040928; Thu, 28 Mar 2013 14:10:40 -0700 (PDT) Original-Received: from kwarm.red-bean.com (74-92-190-113-Illinois.hfc.comcastbusiness.net. [74.92.190.113]) by mx.google.com with ESMTPS id qn10sm12130596igc.6.2013.03.28.14.10.39 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 28 Mar 2013 14:10:40 -0700 (PDT) In-Reply-To: (Richard Stallman's message of "Thu, 28 Mar 2013 00:20:48 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::233 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:158387 Archived-At: Richard Stallman writes: >I know that Martin Pool no longer works on Bzr. He never told me why, >but I think that Canonical decided to stop funding its development >very much. > >I don't have time to read the Bzr mailing list. Or any development >mailing list. The only such list I am on is this one, and the only >reason I can be on this ls is that I don't follow most of the questions >that come up. You might as well tell me to fly to the moon as tell >me to read something on the Bzr list. > >I read http://stationary-traveller.eu/pages/bzr-a-retrospective.html >before. It says many useful things but does not say anything about >the crucial question: whether Bzr is maintained enough or not. And later: > > The answer to that question should be obvious by looking at the > public repository and developers' list. > >I can't do that -- it is too big a job. I have to find out in ways >that take less time. I am working more than 10 hours a day. Well, really, you don't have time to pay close enough attention to Bzr development to competently decide whether it's still a good choice for Emacs. That's fine -- no one has time to do every important thing, and you do many other important things. But then why do you think you still have the time & mental bandwidth to make this decision well? Why not delegate it to the Emacs maintainers on the grounds that you no longer have time to do a good job of this evaluation? You delegate other things. Why is this special? You wrote: >I hope you understand that before I take the drastic step of giving up >on a package, I need to be convinced there is no hope. People on this >list are proposing that I give up after a snap judgment based on a >weaker criterion. I won't do that. The advice which suggests I do that >is not useful or relevant. The idea that asking one person about one bug will answer the question "Is Bzr maintained enough?" is wrong. Even if someone responds and fixes that one bug, that does not mean there is hope. To correctly assess the chances of hope, you have to look at the overall situation -- which others here have already done, in greater depth and taking more variables into account than you can. Many people in this thread, including myself, have already done a more thorough investigation into the question than you are able to do, given your time constraints, and most have come to the same conclusion. >The help that I need, to make the decision, is to give me the >corrdinates of the specific Bzr bug report about the ELPA branch. >There should be someone on this list for whom that would be quick and >easy. https://bugs.launchpad.net/bzr/+bug/830947, as Eli pointed out later in the thread. The most recent comment on that bug is from November of last year. In https://code.launchpad.net/~rrw/bzr/830947-tree-root-exception there is a patch (not landed in mainline; there is no estimate of whether the patch is ready to land in mainline, nor when it would happen if so). Bug 937101 also gives a workaround recipe in comment #11. But this one-bug approach is a bad way to evaluate overall project health. A single bug is not a proxy for project health. A collection of data points is. If you don't have time to evaluate that collection, and don't have time to trust those who have done so, then your chances of making a good decision are essentially random. -Karl