[Top][All Lists]

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

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIEL

From: Stephen J. Turnbull
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames.
Date: Thu, 02 Aug 2012 14:56:16 +0900

Dmitry Antipov writes:

 > Look at concurrency branch. Everyone agrees that this is an
 > interesting and useful feature,

I don't think that's true.  Emacs needs concurrency, it's true.  It's
not obvious that Emacs Lisp does.  Dynamic scope + concurrency =
nightmare.  You're not going to get RMS (or most Emacs developers) to
give up the former, so the latter is going to need to be seriously
restricted (eg, a GIL).  You're welcome to have a different opinion,
and obviously several people disagree with my assessment.  I'm not
going to argue that point.  But I suggest to you that one reason why
many people who might otherwise be interested in the concurrency
branch don't bother with it is that they agree with me, not you.

 > but no one wants to handle an endless merging efforts.  If we had
 > the same amount of developers as involved in Linux kernel,

It's not the number of developers, it's the customary discipline in
the community.  SXEmacs has a far smaller number of developers than
GNU Emacs does, but they branch like crazy and seem to love it.  Many
projects do.

Merging really isn't that bad if your architecture is designed for it
and your workflow adapted to it.  It's annoying, true, but far less so
than writing tests, or even documentation.

Not to say I don't understand your pain, just that Emacs *can* have an
effective branching-based workflow if Emacs wants it.  bzr is
certainly adequate for such a workflow.  However, bzr was selected
partly because certain folks with veto power didn't want that kind of
workflow for themselves, so making a change is going to take a while.

For you personally, why don't you talk to Miles (aka Mr. Lexbind) and
Eli (aka Mr. BIDI) and see if they have some hints for maintaining
one's own enthusiasm for working on a long-lived branch?  After all,
they did it successfully!  And talk to Eric Ludlam and friends and see
if CEDET has support for the kind of refactoring that you may need to
do, and the Bazaar develoeprs to see how they handle what git calls

reply via email to

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