Re: [ANN] New library stream.el in ELPA

["Stephen J. Turnbull" <stephen@xemacs.org>]

Daniel Colascione writes:

 > I prefer keeping code in master.

Hackers always do.  The vast majority of users aren't hackers,
though.  The vast majority of that vast majority (the half-vast
majority?) loves community package repositories, and for good reason.

N.B.  I have no opinion on stream.el itself.  My opinion is that these
stdlib/package repo issues need to be decided case by case, and that in
general a bias toward putting stuff in ELPA is not a bad thing.  A
bias toward putting everything in core should be avoided in the
current state of the art.

 > That way, it's easily maintained and distributed automatically.

Assuming it's maintained at all, and FVO "distributed" == "to the
hackers who pull from master daily", yes.  To industrial users who get
their core Emacs from Debian or Red Hat, not so.

 > There's very little downside: nobody is going to miss a few tens of
 > kilobytes of compiled elisp.

True but irrelevant, even when the specious "few kilobytes" (due to
one small module) is replaced by the more realistic "many megabytes"
(due to a plethora of small modules and a few monster packages).
There is a lot of experience with standard libraries nowadays.  A
short list of the real tradeoffs involves:

1.  Obsolescence/bitrot of stdlib code.

2.  Maintainer effort to prevent/remediate (1).

3.  Users who need to keep a few modules up to date, but prefer to get
    their core Emacs + from an OS distro.

4.  Developers who always have a current build of master to hand, and
    can easily rollback using the VCS if that breaks, vs. (3).

5.  Paranoid enterprise environments where ordinary programmers have
    to choose software from a list approved by HQ, and there's no
    blanket approval for the package repository.  (Such users' best
    hope for access to new features is a short release cycle that fits
    the convenience of the enterprise's software audit team.)  This is
    really the killer application for "everything in core", but I
    haven't heard this claim in Emacs channels (and the data I've seen
    on distribution of versions in a couple of large enterprises
    suggests that a large majority of industrial users are perfectly
    happy with 5-year-old Emacsen, and a significant minority often
    uses 10-year-old Emacsen).

6.  Variations in development cycles between core and modules, and
    among modules.  Similarity in cycles argues for joint release and
    distribution.

7.  Discoverability of modules in the stdlib is probably higher,
    although as we've seen in several threads recently, even those
    with great interest in the subject can be sadly underinformed
    about the elephant in the room (eg CEDET/EDE).

 > I see no need to flake off useful parts of Emacs and put them into ELPA
 > when the core is not resource-constrained.

You haven't noticed that there just aren't enough developers to fix
all the bugs yet, let alone develop all of the attractive proposals?
That there's only one volunteer for lead maintainer, and he's
politically nonaligned in a flagship product of a political
organization (not to mention having reservations about top management
policy)?[1]

8.  Of course to some extent those resource constraints argue for
    putting everything in core for the convenience of those who *do*
    do a lot of maintenance work on core.

 > For me, using ELPA packages is a bit more awkward,

Emacs is not just about you and other core developers whose practices
are basically similar to yours, though.

 > since I don't use package.el and pull in the bits of ELPA I want
 > manually. If your package is only in ELPA, I probably won't hear
 > about it, and unless it's particularly compelling, I won't use it.

You may be more diligent, but Emacs (like other sprawling language and
framework projects I know of) is such a mess[2] that most hackers won't
use core code if they have to look for it.  It's easier to build your
own, submit/commit, and let Stefan et al. tell you there's a standard
way that also has benefits X, Y, and Z for your application.

9.  This is often a good thing, as the existing code may have
    limitations or even be quite inappropriate for the application to
    hand.  Such experimentation is encouraged by package repos.

I could go on, but I'll stop at 9, according to Guido's Rule of Single
Digits.


Footnotes: 
[1]  I expect these issues to be resolved satisfactorily to all
parties.  But I wonder if John would have stepped forward if someone
who is an enthusiastic advocate of the GNU approach to software
freedom had their hat in the ring?

[2]  Organization of modules is worse than NP-hard.  I have found a
wonderful proof of this theorem but unfortunately it won't fit in a
4-line .sig.