Re: Use DEFAULT argument to completing-read
Martin Buchholz <martin(a)xemacs.org> writes:
The biggest problem of all is that the stable xemacs-21.1
doesn't
really exist anymore. Nobody can get a version of xemacs-21.1 with
all the packages that existed at that time (except by grovelling
through CVS and rebuilding, perhaps).
At what "time"? Note that we had multiple 21.1.x releases.
Suppose your friend wanted a version of XEmacs that `Just
Works'.
What do you recommend?
If he can spare the download volume and is not using IRIX:
XEmacs 21.1.8+sumo. The packages are not nearly in such a awful state
as you describe.
Certainly not xemacs-21.2.27, even though you
use it...
Most of my production work is done on XEmacs 21.1.8+pui installed
latest packages. As I am using AucTeX+reftex
heavily that exactly the ideal situation (20.4 shipped with a broken
reftex).
btw, you'll have to get the packages separately. Hmmm, someone
who
hasn't used xemacs-21.1 for years has just done major upgrades to the
base packages - not all the bugs have been shaken out yet. And no one
seems interested in `back-porting' to xemacs-21.1. And why should
they?
Surely you are talking hypotheticals here. The current system allows
stupid packaging mistakes to slip through sometimes, but Andreas
response time is quick enough to not let this be a problem. This
situation must be improved, but I don't see it as that bad.
Note that the traditional model also can have brown-bag release
mistakes (21.0 comes to mind).
Note that the most major breakage in the packages too date has not come
from 21.2 stuff leaking in but from Mule stuff leaking in the non-mule
version. You want to away with the Mule/non-mule builds too?
One simple rule: if the package developer is primarily a user of
the
development version of the xemacs core, then that package should never
make it by default into the `stable' release (I count packages in the
stable release). ``There is no such thing as portable software, only
software that has been ported.''
Note that a lot of the packages that have been upgraded (in fact ALL
the stuff that has non-bugfix upgrades) have their own testing period.
One the things that packages are good at is coping with elisp that has
its of own release cycle. All the problems you bring up are on the
fringe between the core and packages where the coupling is tightest
(and where there is definitely stuff that we maintain).
IMHO is a mistake to think that bringing everything back into the core
will magically solve all problems and will require no time.
Jan