From: David Kastrup <dak@gnu.org>
To: "Stephen J. Turnbull" <stephen@xemacs.org>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Further CC-mode changes
Date: Wed, 17 Sep 2014 09:30:17 +0200 [thread overview]
Message-ID: <87bnqevh4m.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <87tx4620uv.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Wed, 17 Sep 2014 15:54:32 +0900")
"Stephen J. Turnbull" <stephen@xemacs.org> 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
next prev parent reply other threads:[~2014-09-17 7:30 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-02 5:26 POC: customizable cc-mode keywords Daniel Colascione
2014-05-10 23:13 ` Daniel Colascione
2014-05-11 21:13 ` Alan Mackenzie
2014-05-11 21:23 ` Daniel Colascione
2014-05-16 17:52 ` Alan Mackenzie
2014-05-16 18:06 ` Daniel Colascione
2014-05-18 21:33 ` Alan Mackenzie
2014-05-18 22:28 ` Daniel Colascione
2014-05-19 2:25 ` Stefan Monnier
2014-05-25 18:08 ` Alan Mackenzie
2014-09-08 17:28 ` Stefan Monnier
2014-09-11 13:55 ` Further CC-mode changes Stefan Monnier
2014-09-12 23:59 ` Alan Mackenzie
2014-09-13 1:09 ` Ivan Andrus
2014-09-13 10:04 ` Alan Mackenzie
2014-09-13 3:04 ` Stefan Monnier
2014-09-13 15:10 ` Alan Mackenzie
2014-09-13 19:24 ` Stefan Monnier
2014-09-13 23:08 ` Syntax-propertize and CC-mode [Was: Further CC-mode changes] Alan Mackenzie
2014-09-14 4:04 ` Stefan Monnier
2014-09-16 17:30 ` Sync'ing cc-mode Stefan Monnier
2014-09-26 19:19 ` Stefan Monnier
2014-09-15 20:24 ` Further CC-mode changes Glenn Morris
2014-09-16 3:07 ` Stephen J. Turnbull
2014-09-16 13:39 ` Stefan Monnier
2014-09-16 14:22 ` David Kastrup
2014-09-16 23:40 ` Stephen J. Turnbull
2014-09-17 1:02 ` Stefan Monnier
2014-09-17 1:48 ` Stephen J. Turnbull
2014-09-17 5:22 ` David Kastrup
2014-09-17 13:00 ` Stefan Monnier
2014-09-17 18:31 ` Glenn Morris
2014-09-17 19:12 ` David Kastrup
2014-09-17 5:24 ` Eli Zaretskii
2014-09-17 6:54 ` Stephen J. Turnbull
2014-09-17 7:20 ` Eli Zaretskii
2014-09-17 7:30 ` David Kastrup [this message]
2014-09-17 13:04 ` Stefan Monnier
2014-09-17 18:25 ` Glenn Morris
2014-09-18 5:20 ` Stephen J. Turnbull
2014-09-18 9:44 ` Emilio Lopes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bnqevh4m.fsf@fencepost.gnu.org \
--to=dak@gnu.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=stephen@xemacs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).