Re: Will Martin contribute to XEmacs in the future?

mb> Here are my recommendations for future XEmacs development: Thanks! mb> I don't know how anyone can live with the hideous progress mb> guages on Unix. Turn them off by default. 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. ESD _is_ off, I thought. If it's not on your platform, I'd like to know details. 2001-07-22 Stephen J. Turnbull <stephen(a)xemacs.org&gt; * 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. I wish. Not practical in current circumstances, sad to say. mb> If necessary, introduce the concept of "expected" failure. Done in 21.5, not yet synched back to 21.4. With that boot in the pants, I'll submit a patch. With your suggestion and nearly 6 months in 21.5, I bet Vin will take it. (See log below.) To make improvement of test-harness.el easier, and more easily usable in packages, I have been considering moving it to xemacs-devel or perhaps xemacs-base. To be effective, this requires distribution of that package with XEmacs, which is something you've always wanted (and mention here). Also, I think the regression tests (at least) should be a package, or perhaps part of xemacs-devel. Your comments on this approach would be appreciated. 2002-10-19 Stephen J. Turnbull <stephen(a)xemacs.org&gt; * automated/test-harness.el (test-harness-expect-bug): New variable. (Known-Bug-Expect-Failure): New macro. (Skip-Test-Unless): New macro. 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. That's partly because I at least explicitly disagree with some of those criteria. If you would be specific about your criteria, it would be a lot of help to the 21.5 engineer, and to me (likely to find myself in that position again in the near future). mb> The work on packages is not yet finished. It's still far too mb> easy for a non-user system administrator to install an XEmacs mb> which is essentially useless because the packages aren't mb> installed. I am a believer in "batteries included". Work in progress. 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. Probably. But for those who want a gated community, there's an easily accessible one at gnu.org. That model also has its disadvantages, and most of us are at xemacs in part because of a strong preference for the more free-wheeling environment we now have. As for personal trees (CVS branches), that's been explicitly on offer since mid-2000. Several people on the Review Board have taken advantage of the opportunity, but nobody really likes working that way under CVS. So everybody wants to merge to trunk. The personal releases model also suffers from the fact that several reviewers perceive multiple branches as creating competition for testers. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.j