Re: Syncing Gnus and Emacs repositories

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Jeez, guys, I just asked a honest question, because I really _wanted_
 > to understand whether Stephen knew something about the Unicode branch
 > that I didn't.

I don't claim to know anything special about the Unicode branch,
because in fact I don't.  What I do know about from experience is what
happens when you try to conduct mainline development on a CVS branch,
and I have enough knowledge of what is involved in Mule work and in
converting from Mule code to Unicode to be confident that
emacs-unicode-2 is not exempt from the generic problems.

Your questions may have been "simple" and "honest" to you, but they
looked like attempts to score debating points to me.  Here are my
"simple" and "honest" answers:

 >>> So in that case, making such changes in the Unicode branch directly,
 >>> as I suggested, would be a good way of installing changes without
 >>> interfering with the future merge, right?

 >> Assuming that those making changes in the Unicode branch are
 >> thoroughly familiar with it, yes.

 > Are you sure such a thorough familiarity is indeed required?  AFAIK,
 > most of the radical changes in the Unicode branch are fairly
 > low-level;

Statistically, I'm sure.  If extra work is conducted on the branch,
there is some probability of collision.  Since by definition that work
is too disruptive for the trunk, I suppose it's higher than you might
otherwise think.  The more work you force into that branch, the more
disruption.  It's possible that no mistakes will be made.  Why risk
that they will?

 >> Bottom line: The risks are high, the benefits are small.

Nobody has proposed any significant benefits to this, except that it's
a "compromise".  Why take *any* risk, just for the sake of a nominal
compromise?

OTOH, all of your arguments *do* apply to opening the trunk to merge
of emacs-unicode-2 (and other disruptive features).  I see very little
risk in opening the trunk *now*, not even in terms of packages that
would be ported to Emacs 22.2-on-the-trunk but not Emacs
22.2-on-a-branch.

 >> I strongly recommend against doing substantial work on a CVS
 >> branch

 > Well, the Unicode branch exists for a long time, so we are already
 > there.

[That is not an attempt at dialog!]

 >> unless it has a single theme and is explicitly aimed at a single
 >> merge to mainline, then retirement.

 > I don't see how the CVS deficiencies are not relevant for a
 > single-theme development.

Because in single-theme development the flow is one-way, from trunk to
branch, until you decide to merge.  You don't even want to port typo
fixes in docstrings back, because they *will* cause merge conflicts.
This discipline is easy to maintain in single-theme development.

It is much harder to do with multiple developers who think of the
branch as "home" to their projects, but not of themselves as members
of all the projects.  It sounds counter-intuitive, but it is a fact
that such merge conflicts creep in.  Surprisingly often they strike in
places where it's hard to determine which hunk is the "true" one.[1]
I recall on several occasions looking at a pair of hunks, one of which
I wrote, but not knowing which one!  In CVS it's not easy to find out,
you need to talk to the server.

Second, effectively a line of development where independent projects
are being conducted is in a continuous state of merge.  Conflicts
arise, collisions in simultaneous commits are very hard to straighten
out since CVS commits to multiple files are not atomic, and the
repository ends up being inconsistent with *all* developers'
workspaces.  Your best hope of keeping this straight is to use CVS
itself to keep individual projects on subbranches, but then you *do*
run into the CVS deficiencies with branch-to-branch work.

 > In any case, I think switching to Unicode can hardly be classified
 > as ``single-theme'', since it touches so many internals.

[Another dialog-killer.  Obviously, I had a reason for classifying it
so.  Why do you deny it without asking WTF I'm talking about?]

Let me quote from a master:

    I will contend that conceptual integrity is *the* most important
    consideration in system design.  It is better to have a system
    omit certain anomolous features and improvements, but to reflect
    one set of design ideas, than to have one that contains many good
    but independent and uncoordinated ideas.  ... It is not enough to
    learn the elements and rules of combination; one must also learn
    the idiomatic usage, a whole lore of how the elements are combined
    in practice.  ... Every part must even use the same techniques in
    syntax and analogous notions in semantics.  Ease of use, then,
    dictates unity of design, conceptual integrity.  Conceptual
    integrity in turn dictates that the design must proceed from one
    mind.... [Frederick Brooks, _The Mythical Man-Month_, Ch. 4]

The emacs-unicode-2 branch is mostly the work of one man, Ken'ichi
Handa.  Having observed Handa-san's work in the past, I'm willing to
bet it has conceptual integrity.  In other words, it has a theme:
changing the internal coding from Mule coding to Unicode while
maintaining the look and feel of Emacs and conforming to Unicode.  All
of the myriad of little changes can be described by that theme.

As you point out from a different point of view, as soon as it gets
merged to trunk, that conceptual integrity will start to break down.
But at that point, the theme is *part of Emacs*, and the developer
community will quickly come to learn to try to conserve it.  As long
as it's on a branch, it has no such status, it must fend for itself.
If in that branch it must compete with other independent projects for
attention, the conceptual integrity will start to degrade.  This isn't
part of my XEmacs 21.4 release experience, but I've observed both the
instinct to conserve "XEmacsness" and degradation of conceptual
integrity on many occasions in XEmacs.

For a question as central to a text editor as "what is a character?",
I think conceptual integrity is something to be preserved at almost
any cost.

Once again, I don't contend this all is always true, but in this case
I see significant risk to the strategy of opening emacs-unicode-2 to
commits other than those approved specifically by Handa-san, and no
gain.


Footnotes: 
[1]  Bram Cohen of BitTorrent fame claims that his "patience diff"
algorithm helps this a lot, but none of the projects I work on use bzr
yet, so I don't know.