Re: Will Martin contribute to XEmacs in the future?

mb> I am not convinced that packagizing the tests is a good idea. mb> It would discourage testing by users. It would still be available by make check. My basic plan (not approved or implemented yet) for source distribution is xemacs.tar.gz -> contains sumos. xemacs-src.tar.gz -> contains whatever is needed to bootstrap packages, regression tests, etc. CVS would need something, but probably a dodge like checking out the tests package as a submodule would work. I would not move the tests to packages until this is in place. mb> In general, unless disk space is an issue, tests should be mb> distributed with the sources that they test. In the above framework, tests would be available in the same distribution as the sources being tested. However, with packagization they would become a true regression test, and would also allow us (and users) to backtrack pre-existing bugs. (For example, every XEmacs released in the 21.5 series fails the same tests in regexp-tests.el that 21.4 does, as do 21.1.14 and 21.1.9. I think we can presume that 21.2.xx all do, too.) mb> The Linus model is not a gated community; I didn't mean to imply that the Linux kernel community was. However, our relative lack of resources is not likely to support a free- wheeling community like Linux's. mb> For XEmacs, the stable branch is run Linus-style by Vin, mb> fairly successfully. Vin has done a good job. But the stable branch is not where the code you worry about is introduced. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.