Stephen J. Turnbull wrote:
David Kastrup writes:
> I was talking of control. Code which can only be understood and
> managed by an inner kabaal or single persons because of its
> inherent design decisions and resulting complexity is a much more
> absolute lock-in than even copyright.
I'm not going to argue that Richard's decision was insane on technical
grounds; it was not.
But the claim that letting Lucid go ahead with the merger unmolested
was risking "absolute lock-in" is nonsense on the face of it. "rm -rf
emacs; tar xzf emacs-18.59.tar.gz" cures any such lock-in in theory,
and in practice, Richard had already done something far more dramatic:
"rm -rf emacs; mkdir emacs". Richard is a hard man to lock in! At
worst, if the product of a Lucid merge had to be abandoned completely,
with no code surviving into GNU Emacs 19, the cost would only be a few
months. And the upside was *huge*.
> And the Lucid programmers basically said that: we want this in now, in
> the shape we consider fit, and under our control. You don't get to
> criticize or cherry-pick, you don't get to voice wishes, you don't get
> to review.
No, AFAIK they never said "we want this in" at all. Feel free to
point it out if they did. What they said was: "if *you* want *us* to
do the merge work *now* ...". The rest of your paragraph is accurate
enough, except that it ignores the fact that the merge would take
maybe a couple of months, and after that RMS could do all the
reviewing he wanted, and throw out any rotten cherries.
Sure, this does risk some extra, annoying work, and for that reason
your opinion that:
> From a point of sane software and project engineering, I consider
> Richard's choice given the options wise.
is plausible, although I disagree.
> Emacs does not have stasis areas where people are waiting for
> Richard Stallman, or Gerd Möllmann, or even Kenichi Handa to keep
> maintaining stuff they created and nobody else understands.
Neither did Lucid Emacs 19.6 have "stasis areas". You can't compare
to XEmacs today, which is much more bloated, with much code written by
far less professional programmers,
IMHO this isn't XE-specific. Remarked in GNU code
things solved again and again in a (slightly) different
way. Proposed a general-purpose collection than, which
ended up at least in string-strip.el.
IMHO all Emacsen would gain a lot, if more code-critic
occurs. Understand, its hard to do, as people might
feel upset or wouldn't want to criticise each other.
AFAIC please be always invited to propose better
written solutions than I did... :)
than the code that Richard wanted
Lucid to merge.
XEmacs-Beta mailing list
XEmacs-Beta mailing list