stdlib for Emacs? [was: async 1.0]

[Stephen J. Turnbull]

Christopher Schmidt writes:

 > Slightly off topic...  I do not agree with GNU ELPA not being applicable
 > for core services.  I think every single package that is not absolutely
 > necessary for running a bare Emacs should be moved to GNU ELPA.

If you want to know what that would look like, look at XEmacs.  It's a
win for XEmacs, but I have to suspect that win has a lot to do with
getting free maintenance for the core of many packages that are core
parts of Emacs, plus a different development culture (see below).  The
XEmacs packagization side either has a volunteer maintainer --
sometimes the core maintainer but we prefer not to burden them if
another volunteer is available -- or it's done by the "XEmacs Dev
Team".  Note that packages maintained by the dev team typically have
much longer response times, etc, even when there is an upstream.

It's not obvious to me that it would be a win for Emacs to *move*
those packages to ELPA, even if it would reduce duplication of effort
and cooperation costs.  Ask the Gnus team.

 > On top of that, IMO every single core package should have a copy on
 > GNU ELPA so one can to overwrite the native GNU Emacs one with the
 > one from GNU ELPA.  This would decouple all packages from the Emacs
 > release cycle and allow bug fixes to be distributed instantly.

Bug fixes are already mostly distributed instantly, by bzr.

So AFAICS what you are claiming is that this would speed up
distribution of bug fixes to users who don't care enough about Emacs
to build it themselves.  This is very unlikely based on XEmacs
experience.  AFAICT, such users mostly get their fixes when they are
picked up by the OS distros, but guess what?  The distros don't
distribute upstream binary packages, they build their own from their
own repos which are (near) clones of Emacs's or upstream.

 > On top of that, this would make actual core emacs development,
 > test, release and bug management a lot easier.[1]

No.  It only helps if package distribution is completely decoupled
from Emacs distribution, but this would be very costly to the Emacs "I
can hack any part of Emacs" mindset because it would require codifying
a lot of APIs that are currently more or less internal.  (The
fungibility of "internal-ish" APIs causes me a certain amount of
hair-tearing every time we do a major sync to Emacs, since XEmacs is
by necessity and by preference more friendly to fixed APIs than
Emacs.)  It would also probably result in more integration bugs
getting through to end users.

 > [1] I realise this would require substantial modifications to pretty
 > much every single aspect of GNU Emacs and GNU ELPA.  Yet I think this is
 > an approach worth discussing.

As a gross estimate, it took Steve Baur and a few others about one
man-year of effort to break out the packages that were available in
XEmacs 20.4 for the XEmacs 20.5 release in 1996.  There are a lot more
packages in Emacs now, and it would probably be more effort in total
to do the same for Emacs.

Even in hindsight, I don't think the package split-off in XEmacs was a
mistake.  It didn't turn out as well as hoped, but it could have in
theory, even in the theory I have now.  But Emacs is in a different
situation.  GNU ELPA is successful, let it grow for a while and see
what happens before turning Emacs upside down. ;-)