Re: ELPA policy

[Filipp Gunbin <fgunbin@fastmail.fm>]

I do not consider myself competent enough in this area, but I'd like
to share some thoughts here:

For each package version there is a range (possibly sparse) of core
versions on which the package is supported (or just should work).

While the intent to move as much as possible in ELPA can be understood,
it leads to potentially more incompatibilities between important parts
which can provide API by themselves.

So, there should be some compromise between "latency" of new features
before they generally become available for use in packages and overall
core stability.  To me, it seems that the latter is more important and
it's better to keep infrastructure & library things in core, while
moving everything that uses them for a concrete purpose to ELPA.

If that in turn provides some API which others use, then we have
package interdependencies and that is probably OK (but can lead to
conflicts).  If sufficient amount of important packages use some API
and that API is rather mature, then the maintainer can decide to move
that in core to simplify dependency management.

So, I'd suggest that:

- Language features go straight into core (and people working on them
  / using them will have to use git version of Emacs until next
  release)

- New libraries which are not supposed to be in very common use go to
  ELPA first

- Then they are probably promoted to core as they get mature and more
  widely used - just to simplify their usage ("they will always be
  available").

- Major applications (like Gnus) and smaller ones always go to ELPA
  (most probably we should also bundle them in a tarball, but keep
  outside of the core).  A user can then decide whether to use git
  version of e.g. Gnus (from Elpa or private package repository) if she
  likes, or update to a released package version from Elpa (if core
  supports it), or just keep using the Elpa version she uses at the
  moment (which probably came together with current core).

- If such an application provides things useful for other
  applications, then it probably should extract that into a library to
  go through the cycle oulined above (elpa --maturity--> core).

The API / SPI notion can also be used to provide implementations
(backends) for different features which may have default simple
implementations in core and more advanced ones in packages.  A package
must somehow "register" itself as a candidate for being a service for
a concrete feature during installation.

Filipp