Re: Emacs release and bundling GNU Elpa

[Artur Malabarba <bruce.connor.am@gmail.com>]

I was thinking that keep a list somewhere of packages that we want to
pull from elpa. At build time, these will be copied from "./elpa.git/"
(which will probably be a submodule containing the elpa repo) to
"./lisp/from-elpa/" (which will be a .gitignored directory containing
nothing initially). This should also involve copying info manuals from
"./elpa.git/" to the right place.
I see only two differences from the current situation:

1. Instead of the usual `git pull && make bootstrap` the user wil be
expected to do something like `git pull && git submodule update &&
make bootstrap` which should be a no-brainer (maybe there's a hook or
something that can automatically do the update when `pull'ing).

2. To push a change, instead of editing the file inside
lisp/from-elpa/ you have to edit the file in the elpa.git submodule.
This is a relevant difference, but it shouldn't lead to issues. Since
the from-elpa dir is gitignored, there's no way for people to
accidentally commit changes to it. And having to edit on elpa.git is
certainly an improvement over having to edit on both emacs and
elpa.git.

2015-06-22 16:33 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:
> Fair disclosure: I don't like this "move to ELPA" attitude.  I think
> the net result will be more bugs because of unsynchronized development

Why would it unsynchronise? Everyone who `git pulls` today at 12pm has
the same Emacs. Similarly, under this alternative, everyone who pulls
&& updates today at 12pm will have the same Emacs.

> and less exposure of packages to people who track development on
> master,

These packages will effectively be part of master. Pulling them in
will be a part of the build process, why would there be less exposure?

> and more hassle due to the need to work with more than one Git
> repository, multiple development philosophies, etc.

This is a fine point against moving out of emacs packages that are
only in emacs.
OTOH, we can start with these other two options (a) pull into emacs
packages that are only on Elpa (like company), and (b) move out of
emacs packages that are on both repositories (these are already a
hassle, and the hassle would only be reduced).


> At step 1, we'd have the following novelties:
>
>  . Package developers will have to abide by some of the core's
>    development methodology, like freezing development when core does
>    so, perhaps using release branches, timely fixing of critical or
>    blocking bugs during pretests, etc., let alone abiding by style and
>    documentation guidelines.

Yes. This wouldn't be applied to all of elpa.git, only to those
packages that are bundled in.

>  . Core maintainers will probably start pushing more changes to the
>    packages, something I'm not sure package developers will like.
>    Alternatively, we will have to develop procedures and protocols we
>    don't currently have for having the package developers themselves
>    expedite fixing of certain problems deemed urgent.

Yes, this is something the package developer would have to be aware,
in order for a package to be bundled in. Nobody is forced to bundle a
package in Emacs.
OTOH, for packages that are currently on both repos this already
happens, and it will be much better if for the developer if these
changes are all made to the same place.

>  . We'd need to find a way of providing ChangeLogs for the packages,
>    either by merging their Git logs somehow, or by keeping their
>    ChangeLogs in separate directories (which would mean each package
>    will have its own directory, making load-path longer).

Keep their ChangeLogs in the same place as their source (in the
"./elpa.git/packages/package-name/" directory). This has nothing to do
with the load-path. The load-path will point to "./lisp/from-elpa"
(which is where we copy the sources before compiling).

>  . We'd need to produce NEWS entries for the packages, which will
>    probably mean the packages will have to maintain their own NEWS
>    files, using the same methodology and style as in core development.

Yes. That can sit alongside the ChangeLog.

>  . If any of the packages have manuals, or are mentioned in the Emacs
>    manuals, changes there will have to be merged as well, and we will
>    have to track those updates, e.g. like we do in NEWS.

As I said at the start. Just like the sources are pulled in at
compiled time, so are their manuals. Changelog entries for edits to
the manual go in the package's ChangeLog.

>  . Our defcustom's have a ':version' tag, which is useful for quickly
>    examining new options since some release -- how will this work in
>    packages whose release cycle is not synchronized with Emacs?

They will use the :package-version tag. Like packages have always done.