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

[Dmitry Gutov <dgutov@yandex.ru>]

On 15.12.2020 22:11, Eli Zaretskii wrote:

>>> 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?
>>
>> I'd expect it to work the same as for Org, MH-E, Gnus, you name it.
> 
> What do you mean by "the same as"?  Currently, it is not our decision
> which Org/MH-E/etc. version will be in what Emacs branch.  The
> respective developers make that decision and simply push the version
> they decided into our repository.
> 
> Once we separate the repositories, the decision will have to be made
> by whoever prepares the tarball, and I don't see how he or she could
> be equipped to make that decision, nor how the packages are organized
> for this modus operandi.

Forgive me if that has already been suggested, but how about either:

- When making an Emacs X.YZ release, we require that every "external" 
package has a tag emacs-xyz in its repository, and we pull in and 
package that version.

- In the very same file in Emacs' tree that the repositories with 
external packages will be listed, we also list the corresponding 
revisions that will go into the upcoming release.

The latter is essentially the "git modules" model, which we can also 
use. One advantage it has is that the package author forgotten to push a 
tag for some Emacs release, we're still covered.