>>>> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
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>
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>
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