Stephen> I personally see no particular need to _have_ a HEAD. ms> But we do. All sorts of CVS history doesn't work on a branch. Yeah, it also occurred to me later that besides the history stuff, status information will be human-unreadable if we get too far away from HEAD. So I guess we do need a HEAD. But I see these issues as a bug in CVS. Current XEmacs development is more a forest than a tree. We don't really _have_ a mainline at this point, except by administrative fiat and historical accident. Besides 21.2, there is 21.2/Mule/NT, 21.2/UTF-2000, and soon 21.2/gtk-xemacs. Some of these features will probably merge soon, others not. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

Simon> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: Simon> Is there a reason for all of these not being configurable Simon> by --with-gtk or similar? Yes. GTK for 21.2 doesn't exist yet AFAIK. Simon> Right now I have xemacs-21.1, xemacs-21.2 and gtk-xemacs Simon> checked out, and I'd like to test UTF support.... creating Simon> different branches for every projects is a nightmare in Simon> CVS. Wrong emphasis IMO. Having multiple concurrent projects is a nightmare, no matter what management system you use. Note that UTF-2000 and GTK/XEmacs are _forks_ (== separate projects not governed by the XEmacs Review Board), not branches. I want to bring these forked tasks back into the project in a systematic way. Simon> IMHO, giving someone a branch to work on creates more Simon> problem in the long-run than making all development take Simon> place on HEAD, hidden by --with-foo (defaulting to off) Simon> switches for experimental stuff. Could be. But (IMO) this implies a return to the cathedral, with REAL vetos exercised on a whim, by a small group, ideally _one_ person, per module. Right now, we have dozens of committers, and absolutely no control over what they commit except their sense of self-restraint. And they like it that way. An attempt to return to the cathedral would blow this project apart. Simon> A project replacing, say, the garbage collector, inside a Simon> branch might make it hard to integrate it with HEAD in the Simon> future. If done in HEAD from start with a configure Simon> switch, it would only require flipping the default value Simon> once it's ready. It's not so simple. Doing this in the obvious way (using patch --ifdef=NEW_GC) works fine with _one_ project. Think about what the code would look like after a couple of weeks with Bill using patch --ifdef=GTK, Ben using patch --ifdef=MULE_NT, Tomo using patch --ifdef=UTF2000, and Olivier with patch --ifdef=PDUMP. What's going to happen is that Olivier wins big (pdump is basically orthogonal to the other projects)[1], and the other three give up in disgust and/or fork the project. They are necessarily going to collide occasionally, and the MULE_NT and UTF2000 #defines are going to be locked in a death-match over broad swathes of code. Wishing this away by doing all development on the trunk isn't going to work. What it will do is create ex-ante politics as some developers will try to preempt certain areas as their private domain _before_ their projects are working. I think the ex-post politics of integrating demonstrated working code (eg, GTK) will result in better features and a more reliable product. Furthermore, the effort involved in keeping strict #defines, plus the collateral damage to people who need to understand that code but don't want to work on it, must be set against the costs to the feature creatures of a post-success merge. Now suppose you take the lazy way out. You don't use patch --ifdef, you just rely on the developers to put in appropriate #ifdefs. And let them make "small" changes that "are simply better" without an #ifdef. Then a mistake (and even Marti(a)ns make mistakes) takes out the whole project for hours. Assuming it's a _show-stopping_ mistake. If it's non-fatal, it can fuck over the other projects for months with intermittent errors. And if the experiment fails, this is nearly impossible to correctly revert. Simon> Also, it's easier for users to test things if they only Simon> need to say --with-foo rather than setup a separate build Simon> environment. These tests tend to be buggy. Simon> And users are everything, aren't they? :-) Yes. But before the product gets to the users, it has to be released. We have enough trouble finding release managers. Steve Baur disappeared before being completely chased out. Martin simply abdicated before doing anything. My retirement is already scheduled for April 2. I see no replacement. More trouble for the developers is an appropriate exchange for a product that actually gets released in my book. And right now Le release c'est moi. :-) I am proposing the things I do in the hope of turning pure hell into a mere job that somebody might conceivably volunteer for. Footnotes: [1] Although he would probably end up in a fight with the NEW_GC guy. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

SJ> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: SJ> Is there a reason for all of these not being configurable by SJ> --with-gtk or similar? If it's on a separate branch, you know that you won't have problems _removing_ the feature from the main line of development. I believe new features should not be in the mainline until at least the author says "feature complete". Then the maintainers get to nag feature contributor with requests for docs, and the inevitable bug fixes before integration into the mainline.

How naive. Of course it's not so simple. The meaning of HEAD is different from command to command. I believe it has been recognized as a misfeature at least and might be fixed at some point. Stefan