Will Martin contribute to XEmacs in the future?
I recently started working at Sun Microsystems. This job is likely to
keep me quite busy, so you are not likely to see me being an active
XEmacs contributor in the future. Now I'm mostly just an ordinary
user with a Real Job. You may see occasional patches from me relating
to getting XEmacs to work on whatever OSes I use for my work (Hint:
http://java.sun.com/j2se/1.4.1/download.html). I have unsubscribed
from most xemacs mailing lists, but remain on xemacs-admin and
xemacs-review.
Because I want an XEmacs that actually works, I will be ignoring 21.5
for the forseeable future. I have finally gotten to the point where
I'm pretty happy with 21.4. Daiki's process fix and my redisplay
speedup patch made a big difference for me. The only bugs remaining
in 21.4 that affect me personally are some hard-to-fix redisplay
glitches, but they are easy to live with. For completeness, there are
a few things I should work on, because it's my work to finish.
(I'm thinking Berkeley DB support here).
Here are my recommendations for future XEmacs development:
I don't know how anyone can live with the hideous progress guages on
Unix. Turn them off by default. All my xemacsen are built
--without-widgets.
Some other experimental features could be turned off by default as
well. I'm thinking esd here.
The idea behind the test suite was to never release an xemacs that
didn't pass 100% on all tested platforms. I recommend that you don't
tolerate any test failures. If necessary, introduce the concept of
"expected" failure. I believe there has been no release of 21.5 that
has met my release criteria since the last one I did the release
engineering for.
The work on packages is not yet finished. It's still far too easy for
a non-user system administrator to install an XEmacs which is
essentially useless because the packages aren't installed. I am a
believer in "batteries included".
If I were to become a major contributor again, I might adopt Linus'
model. Let everyone keep their own tree, and no one gets guaranteed
write access to my tree. XEmacs has been hurt by a too lenient commit
access for core contributors.
Martin