Re: Emacs release and bundling GNU Elpa

[Stefan Monnier <monnier@iro.umontreal.ca>]

>  . 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.

Yup, no worse than what happens for current bundled packages.
I'm not expecting major issues in this respect.  Furthermore, the
pressure to have the latest&greatest version bundled is less severe
since users can easily install a newer version later on.

>  . Core maintainers will probably start pushing more changes to the
>    packages, something I'm not sure package developers will like.

That's part of deciding which packages get bundled.  Again, that's no
worse than what happens with current bundled packages.

>  . 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).

When installed via package.el, they currently each get their own
directory indeed.  Maybe we could combine some of those directories, but
this decision will probably not be based on minor issues such as where
to put the ChangeLog entries.

>  . 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.

I was thinking of putting the NEWS entries of those packages in the
normal NEWS file.  They'd be updated by hand when we change the version
of this elpa.git package that the emacs.git tree refers to
(remember emacs.git wouldn't just say "bundle company", but "bundle
version <foo> of company").

>  . 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.

package.el already knows how to handle manuals, and while we may decide
to handle it slightly differently, I don't foresee any major issues
there (at least none that are really important to solve).

>  . 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?

Good question.  This one has existed for a long time and is not directly
related to whether ELPA packages get included in Emacs's tarball.

>    At the very least, some changes to support that in
>    customize-changed-options will be needed.
>    Similarly with make-obsolete: we will need at least some
>    standardized wording for the WHEN argument, to avoid confusion
>    between versions of Emacs and the packages.

No.  We can keep living with these problems unsolved.  Of course, I'd be
happy to see them solved, but bundling ELPA packages doesn't make them
significantly more pressing.


        Stefan