Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added

[John Wiegley]

>>>>> "SM" == Stefan Monnier <address@hidden> writes:

SM> There are several gradations of dependency, of course:

SM> - Can src/emacs be dumped without that package?
SM> - Can all of lisp/**/*.elc be built without that package?
SM> - Can all of lisp/**/*.el be used without that package?

SM> If all three answers are yes, then it doesn't need to be "core". If all
SM> three are no, then it definitely needs to be "core". Between the two,
SM> well, ...

This is a great distinction, Stefan. I guess we have several degrees of
propinquity in core:

  0. It's in C
  1. Emacs Lisp that is dumped into src/emacs
  2. Emacs Lisp that is required to compile all of lisp/
  3. Emacs Lisp that is required to use all of lisp/
  4. Emacs Lisp that is in core, but stands alone
  5. Emacs Lisp that should be in the distribution tarball          ELPA tarball
  6. Emacs Lisp that should be installed using M-x package-install  ELPA
  7. Emacs Lisp that is not signed over to the FSF

The reason to move something from levels 1-3 into ELPA is managerial: to more
easily accept version updates from an outside development team. Something
stable that has become "part of Emacs" should still fully move into core.

The reason not to move #4 into ELPA is historical: It's a stable package and
we don't gain anything by doing so.

The reason to move #5 into ELPA is likewise managerial, but is much easier to
justify: the development and use of the package was largely separate from
Emacs anyway, except for added testing by being part of the test builds.

#6 stays in ELPA.

#7 contains a ton of code that we'd like to move into ELPA, and maybe it'll be
easier to encourage it, once people see the new attention we're paying here.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

signature.asc
Description: PGP signature