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,

Lucid to merge. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta