From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Further CC-mode changes Date: Wed, 17 Sep 2014 09:30:17 +0200 Message-ID: <87bnqevh4m.fsf@fencepost.gnu.org> References: <53632C6F.5070903@dancol.org> <20140511211351.GC2759@acm.acm> <536FEA43.5090402@dancol.org> <20140516175226.GB3267@acm.acm> <537653A0.2070109@dancol.org> <20140518213331.GB2577@acm.acm> <20140912235948.GA4045@acm.acm> <20140913151055.GB3431@acm.acm> <87vboo2rgk.fsf@uwakimon.sk.tsukuba.ac.jp> <87wq93ve4p.fsf@fencepost.gnu.org> <87egvb2kye.fsf@uwakimon.sk.tsukuba.ac.jp> <831tra4y68.fsf@gnu.org> <87tx4620uv.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1410940021 32590 80.91.229.3 (17 Sep 2014 07:47:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Sep 2014 07:47:01 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 17 09:46:53 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 1XU9wz-00059n-Gy for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 09:46:53 +0200 Original-Received: from localhost ([::1]:42530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XU9wz-0003J3-2b for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 03:46:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36464) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XU9wp-0003FX-3g for emacs-devel@gnu.org; Wed, 17 Sep 2014 03:46:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XU9wR-0001FR-J2 for emacs-devel@gnu.org; Wed, 17 Sep 2014 03:46:43 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XU9wR-0001Cq-G1 for emacs-devel@gnu.org; Wed, 17 Sep 2014 03:46:19 -0400 Original-Received: from localhost ([127.0.0.1]:52465 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XU9h8-0002EQ-63; Wed, 17 Sep 2014 03:30:30 -0400 Original-Received: by lola (Postfix, from userid 1000) id A1068E05F0; Wed, 17 Sep 2014 09:30:17 +0200 (CEST) In-Reply-To: <87tx4620uv.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Wed, 17 Sep 2014 15:54:32 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:174402 Archived-At: "Stephen J. Turnbull" writes: > Of course I'm -1 on anything that makes it even harder for XEmacs to > catch up to current reality. That's where our views of what we are talking about differ. In my book, we are talking about changes that make it even more pressing (but not harder) for XEmacs to catch up to current reality. The whole point of extended backward compatibility upstream is to avoid the consequences of not catching up to reality downstream. > My real point is that bzr has held Emacs back for long enough. Both > Eric's obsession with the 36-24-36 conversion and Glenn's insistance > that everything that is part of the bzr workflow be done for git > *before* the switchover is executed are unfortunate. > > > If you consider the inordinate amount of work Glenn personally > > invested in making bzr usage convenient in Emacs, you might come up > > with an alternative explanation to his alleged "footdragging". > > Sure. The labor theory of value: if I worked so hard on it, it must > be worth keeping. Thing is, bzr was a mistake from day 1, and it went > mostly downhill from there. It didn't for Bazaar: it was the reason for a lot of scalability problems in Bazaar getting ironed out. Of course, doscovery of the wrinkles impacted Emacs development. That was expected. Supporting Bazaar was a political choice in order to keep with a version control system which was looking better suited for the political goals of the GNU projects. A lot of work was expected to make things work well. The technical side of Bazaar progressed to the state of "workable". The political side degressed to "barely workable" after a few years. Which makes it a lost investment. Which does not mean that all investments of labor in the view of political goals must be lost investments, or we would not be having a GNU project. > The consequent duplication of effort was not Eric's fault! The country of Oz has pronounced a travelling warning for strawmen on the Emacs developer list as they are in serious danger of being rounded up and beaten to death. -- David Kastrup