emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Further CC-mode changes


From: David Kastrup
Subject: Re: Further CC-mode changes
Date: Wed, 17 Sep 2014 09:30:17 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

"Stephen J. Turnbull" <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]