Thanks for the report and the bug fix. It will be in the next release of Dired. Note that it would have been more appropriately submitted via M-x dired-report-bug RET which makes it more likely that I notice it. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

Karl> Will someone please see that the patch gets applied to Karl> `xemacs-package' asap also? It is a rather important Karl> change. 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 responsibility. 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 again---he's 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 "better". 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."