Re: feature/integrated-elpa 4f6df43 15/23: README added

[John Wiegley]

>>>>> "AG" == Achim Gratz <address@hidden> writes:

AG> If Emacs takes packetization of the core seriously, then the "hard core"
AG> should contain just the stuff that is needed for bootstrapping Emacs.
AG> Everything else should be a package. Single-file packages would live in
AG> one directory together, and multi-file packages would be in their own
AG> directory each.

We may get there, but not as our first step. Let me reiterate our plan:

The purpose of the first step is *only* to make ELPA first-class, so that a
package can live primarily in ELPA, but *appear to the end user* as if it had
been developed alongside Emacs. This removes any privileged distinction that
packages living in Emacs.git may have, and encourages future contributions to
move to ELPA. Other than this, there should be no substantive changes.

This will likely require changes to package.el, so that a package distributed
in lisp/ can be updated using package.el. These are the only changes to
package.el that should be necessary initially.

What Emacs developers will notice after this step is that several packages
leave Emacs.git and move to ELPA.git, or back to their points of origin with
release versions in ELPA.git. Nothing at all should change for Emacs packages
that don't move to ELPA.

All this talk about packagizing Emacs.git, so we can manage everything with
package.el (including building and autoloads-generation), and keep everything
into its own directory, is putting the cart before the horse. We're not ready
for that step yet. First, let's make ELPA more useful, then we can talk about
reorganizing core Emacs once this initial phase has seen successful reception
From users.

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

signature.asc
Description: PGP signature