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

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Cc: daniele@grinta.net,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Wed, 16 Dec 2020 11:21:31 -0800
> 
> > 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.

I don't think this is a good idea: bundling a package means that we as
the project assume the responsibility for its quality, which means we
need to be reasonably sure the version we bundle is stable.  This
requires more from the package maintainers, but it's the other side of
having the package bundled.

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

Yes, we will need something like that, and we will need a mechanism to
make a checkout of the Emacs Git repository included the bundled
packages more or less automatically, so that builds from the Git
repository still work as they do today.  See the other discussions in
this thread for the details.

We need to figure all that out, and have this set up for each package
we want to bundle, before we bundle it.