mb> Here are my recommendations for future XEmacs development: SJT> Thanks! mb> I don't know how anyone can live with the hideous progress mb> guages on Unix. Turn them off by default. SJT> I make them "small" but otherwise find them bearable. IMO. mb> Some other experimental features could be turned off by mb> default as well. I'm thinking esd here. SJT> ESD _is_ off, I thought. If it's not on your platform, I'd like to SJT> know details. Well done. Perhaps I was confused by the example in configure.usage: (e.g., `--with-sound=noesd' to disable ESD). You should change that to refer to a feature that defaults to ON. SJT> 2001-07-22 Stephen J. Turnbull <stephen(a)xemacs.org&gt; SJT> * configure.in (with_esd_sound): Default to no. mb> The idea behind the test suite was to never release an xemacs mb> that didn't pass 100% on all tested platforms. I recommend mb> that you don't tolerate any test failures. SJT> I wish. Not practical in current circumstances, sad to say. mb> If necessary, introduce the concept of "expected" failure. SJT> Done in 21.5, not yet synched back to 21.4. With that boot in the SJT> pants, I'll submit a patch. With your suggestion and nearly 6 months SJT> in 21.5, I bet Vin will take it. (See log below.) SJT> To make improvement of test-harness.el easier, and more easily usable SJT> in packages, I have been considering moving it to xemacs-devel or SJT> perhaps xemacs-base. To be effective, this requires distribution of SJT> that package with XEmacs, which is something you've always wanted (and SJT> mention here). Also, I think the regression tests (at least) should SJT> be a package, or perhaps part of xemacs-devel. Your comments on this SJT> approach would be appreciated. SJT> 2002-10-19 Stephen J. Turnbull <stephen(a)xemacs.org&gt; SJT> * automated/test-harness.el (test-harness-expect-bug): New variable. SJT> (Known-Bug-Expect-Failure): New macro. SJT> (Skip-Test-Unless): New macro. Well done. The design of the test harness interface is good, but the implementation is not something I'm proud of. I took the implementation of the byte-compiler framework and hacked it till it was a test harness, and you can probably still find a few byte-compilerisms in test-harness.el. A cleanup of test-harness.el is a good project. I am not convinced that packagizing the tests is a good idea. It would discourage testing by users. In general, unless disk space is an issue, tests should be distributed with the sources that they test. mb> I believe there has been no release of 21.5 that has met my mb> release criteria since the last one I did the release mb> engineering for. SJT> That's partly because I at least explicitly disagree with some of SJT> those criteria. If you would be specific about your criteria, it SJT> would be a lot of help to the 21.5 engineer, and to me (likely to find SJT> myself in that position again in the near future). Get lots of diverse machines with lots of diverse compilers. Build xemacs with lots of diverse options. Run make check with each build. Completely automate this. Get friends on the Net to give you access to odd machines. Get obsolete PCs and install odd OSes like OpenBSD on them. Get icc for Linux. Build debug and optimized. Build with and without union-type. Push the envelope on optimized builds, including ANSI aliasing. I'm still greatly annoyed by Ben breaking my AIX cc (with ANSI aliasing) build, me fixing it, and Ben deliberately undoing my fix. I assume 21.5 is still broken with regard to ansi-aliasing, and still consider it unacceptable. mb> If I were to become a major contributor again, I might adopt mb> Linus' model. Let everyone keep their own tree, and no one mb> gets guaranteed write access to my tree. XEmacs has been hurt mb> by a too lenient commit access for core contributors. SJT> Probably. But for those who want a gated community, there's an easily SJT> accessible one at gnu.org. That model also has its disadvantages, and SJT> most of us are at xemacs in part because of a strong preference for SJT> the more free-wheeling environment we now have. The Linus model is not a gated community; it's a freewheeling community. But that doesn't mean you get to commit to Linus' tree. Linus is successful in spite of (or perhaps because of) being a bastard. For XEmacs, the stable branch is run Linus-style by Vin, fairly successfully. SJT> As for personal trees (CVS branches), that's been explicitly on offer SJT> since mid-2000. Several people on the Review Board have taken SJT> advantage of the opportunity, but nobody really likes working that way SJT> under CVS. So everybody wants to merge to trunk. CVS sucks for branches. Switch to something else, medium-term. SJT> The personal releases model also suffers from the fact that several SJT> reviewers perceive multiple branches as creating competition for SJT> testers. True. Freedom of choice implies terrible inefficiencies. Martin

I went to CodeCon this year (www.codecon.org) where there was a panel on source code control systems. Scroll down to the bottom: http://codecon.info/2003/program.html Consider using Perforce from http://www.perforce.com/ . Free projects are eligible for free licenses. It is so easy to use in comparison to CVS and much more reliable. There is even an emacs mode ... Fabrice

MS> Experienced developers I know have told me that Perforce is certainly MS> nicer than CVS, but that its support for branches is "confusing." Maybe they are too used to cvs ? ;-) Other people who use it think is it easy to use. And Perforce argue that's their main strength. Fabrice (who _does not_ own Perfoce shares ! :-))

Fabrice Popineau <Fabrice.Popineau(a)supelec.fr&gt; writes: Yes, I'd agree with that. I've always found branching in CVS a nightmare but with Perforce it just works. Branching in Perforce is a lot like copying a directory tree, a concept that _all_ developers are familier with. Just my $.02. -- tim writer <tim(a)starnix.com&gt; starnix inc. tollfree: 1-87-pro-linux thornhill, ontario, canada http://www.starnix.com professional linux services & products