Richard Cook writes:
Totally agreed on all counts. Make it work in both places, or
better yet, just include sumo! Does having lots of packages in the
release have any downside? Does it slow things down, introduce
bugs, or what?
There currently is no provision at all for packages in the release.
It's not as easy as "just include"; provision must be made to install
in the right place. That's non-trivial (think root vs. non-root), and
there are disagreements about how to think about package installations
that will have to be settled to actually get this in the distribution.
There is also a requirement of backward compatibility with the stable
You're certainly welcome to do the work. Be warned that it's a fair
amount of work (I've tried before but ran out of tuits very quickly),
likely to be endlessly bikeshedded, and in the end, nobody will
actually notice it's been done. :-) Inclusion of a standard library
of packages with XEmacs will surely slow down the release process, as
it does in Python (where the standard library policy is an endless
source of discussion on their dev lists). The bigger the stdlib, the
more drag it will create, I believe.
Moving packaged libraries back into core has huge downsides. First,
it means that the libraries now have stable and unstable versions,
both of which need to be maintained (and in general the stable version
will be defacto unmaintained, and definitely will not get any
improvements). Worse, the library will not be moved into the stable
version (if it is, we then have two unstable versions, one of them
correctly labeled and the other a lie :-); that means that we have two
different procedures and contexts for loading the library. Third, two
different contexts for updating the library with new versions.
Fourth, for externally maintained libraries (which in theory includes
dired and efs), it will double (at least) the burden on the
maintainer. Fifth, it will surely slow down the release cycle for
improvements and bugfixes alike.
XEmacs-Beta mailing list