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

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

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

You tell me how you want it to work, and we'll write the support
code accordingly.  E.g. one way this could work is as follows:

Currently every GNU ELPA package has a corresponding branch
`externals/[PKGNAME]` in `elpa.git` where the source code is kept.
We could add to elpa.git a bunch of branches `emacs/[PKGNAME]` which
keep the version of the code we want to include in the next release
of Emacs.  Those branches can be updated whenever we or the package's
maintainer deems appropriate.

Our tarball-builder-script would then grab the bundled packages's code
from those branches.

> I'm not sure most of it is done.  Over the years, we had several long
> discussions here about this stuff, and AFAIR none of them ended with
> solutions.  All those issues raised in those discussions are still
> with us, waiting to bite us.

Most of the harder discussions have to do with the unsolvable problems:
E.g. we'll have code in the tarball that's not present in a Git
checkout, which means that people who work from the Git may
be disappointed.  We could "fix" that by making our Git script fetch the
extra code as well, but what about those that don't want it (or what
about the extra complexity of having to pull/update those branches)?
Also, the proposed bundling doesn't let Emacs's own code depend on GNU
ELPA code, so it still wouldn't allow us to use `dash.el` inside Emacs.

I don't see any need to "solve" or discuss those issues before we can
bundle packages.

> We need to go over those issues and solve them before we can seriously
> talk about unbundling ada-mode or any other package.

I'm not talking about unbundling anything here.  I'm talking about
bundling *additional* packages currently not distributed with Emacs.
[ BTW, ada-mode is already "unbundled", AFAIK.  ]

Obviously, the ability to bundle GNU ELPA packages might allow/encourage
moving some packages from Emacs to GNU ELPA.  It's indeed one of the
longer term benefits that makes bundling interesting, but in the short
term (i.e. Emacs-28), this is not on the table AFAIK.


        Stefan