>>>> "Karl" == Karl M Hegbloom
Karl> Will someone please see that the patch gets applied to
Karl> `xemacs-package' asap also? It is a rather important
Michael _is_ the dired maintainer _for XEmacs_.
Now that I've got that out of my system, let me explain how things are
working in practice. We're trying to dissociate code development
leadership, aka _maintainer_ship, from release engineering, ie code
_management_. Both are big jobs. Some people are good at, like to do,
and have time to do both. They are few. So divide the jobs.
This is basically the Linux distro model (at least as defined and
mostly practiced by Debian, as Karl knows well). True, that has a
separate motivation due to diversity of platforms. Since there's
really only one Emacs platform that distributes a broad range of third
party packages, our primary motivation is allocation of authority and
Remember, even though the Dired bug in question is very dangerous if
it manifests, it cannot be fixed by patching the source and releasing
a new package. _Every admin must also update._ This update lag means
that any bugs introduced by the fix will also remain in the ecology for
a long time -- and may affect a much broader population of users (eg
the "testing EFS" thread http://list-archive.xemacs.org/xemacs-nt/
It is the maintainer who is in the best position to make those
judgements. Sometimes it's better to apply a little grease to all the
wheels (and throw away the squeaky one!) The maintainer is delaying
an "obvious and critical" fix for "no good reason"? Think
been through it before, maybe he knows something you don't. For sure,
he knows his user base better. And even if he's wrong this time, on
average he's going to do better than the squeakers.
OTOH the release engineer doesn't know enough. Eg, the XEmacs 21.4.3
release was entirely due to me letting myself be railroaded (mostly by
myself :( ) into applying a "critical fix" for Windows platforms that
prevented any Windows platform from building in 21.4.2. Thus that
decision should be made by the package maintainer/prime developer.
There are dissenters in the core XEmacs Development Team, but several
of our most important maintainers and release engineers (Michael for
EFS and Dired, Vin and myself for the 21.1 and 21.4 "stable" release
series respectively, Steve Youngs for the packages as a whole)
interpret that as the manager must approve, and usually applies/commits
himself, all patches to the code he manages. This approval may be
delegated, where the manager is basically a manager (eg, I only check
for "contained in #ifdef HAVE_GTK" when Bill P approves a patch to
GTK; I could care less if that experimental platform fries your
monitor, you've been warned ;-).
Compare the range of packages XEmacs.org
distributes with those
bundled with GNU Emacs. Compare the average version lags for the
commonly distributed packages. XEmacs wins big on both. That means
our system is currently getting more, better, and more bug-free
packages to the users.
Could we do still better? Surely; nobody's perfect. How? YTMAWBK.
In the meantime, don't let the "best" be the enemy of the
And we're working on it ourselves. I'm sure you notice that Steve
Youngs as package maintainer delegates as much as possible to the
package maintainers, while Vin and I with similarly broad
responsibility, and relatively little detail knowledge of most aspects
of the core XEmacs (speaking for myself, anyway) tend to pull most
decisions "upstairs." This contrast bothers me; I think it's the
right balance but I find it hard to explain why. So we are (off and
on) discussing that kind of issue, and trying to work out procedures
to get critical fixes into release faster, etc. But it's not easy;
most proposals for tweaking the system are motivated by a fix that
fell on the floor, and not by a deep understanding of the context.
"Real Solutions in Real Time for Real Problems of Real People? Real
Soon Now!" (A service mark of Yaseppochi-gumi/Skinny Boy Associates.)
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."