Re: decision on moving core packages to ELPA; also move to obsolete?

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Leake <stephen_leake@stephe-leake.org>
>> Cc: daniele@grinta.net,  Stefan Monnier <monnier@iro.umontreal.ca>,
>>   emacs-devel@gnu.org
>> Date: Tue, 15 Dec 2020 10:53:38 -0800
>> 
>> >> > If so, what happens with installed Lisp files under /usr/share/ ?
>> >
>> > They stay there, but ~/.emacs.d/elpa is earlier in load-path.
>> 
>> And also, once bundling ELPA packages in the tarball works, the package
>> can be removed from Emacs core, simplifying the pakcage maintenance
>> process.
>
> So please describe how you envision the process of building a release
> tarball under this assumption.  E.g., how do I know which version of
> package A I want to bundle is stable enough to go to a bugfix elease
> of Emacs?

The simplest choice is the ELPA version that is current at the time the
tarball is built.

Nominally, ELPA versions are defined to be stable. But given the ease of
releasing a new version via ELPA, some package developers may have a
policy of releasing without significant testing. In that case, it might
make sense to ask developers to put more effort into validating a
particular version for a release. Or simply say such a package is not a
good candidate for bundling.

In my case, I always run a large test suite on ada-mode before I do an
ELPA release.

If we want to freeze some earlier version at the start of release
testing (as opposed to final tarball build time), we'd need some
mechanism to record the versions of all the bundled packages, and then
only use those versions in testing. And a way to change that frozen
version number for a bug fix.

Or ask ELPA packages that are bundled to also freeze for the duration of
release testing; that would be reasonable, and simplify handling package
bug fixes.

-- 
-- Stephe