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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: stephen_leake@stephe-leake.org,  daniele@grinta.net,  emacs-devel@gnu.org
> Date: Tue, 15 Dec 2020 17:01:42 -0500
> 
> You tell me how you want it to work, and we'll write the support
> code accordingly.

I'm not sure mine is the only voice we should listen to, but I try to
outline something below.

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

That would have to be emacs-NN/PKGNAME, where NN is the major Emacs
version.

> Those branches can be updated whenever we or the package's
> maintainer deems appropriate.

Which would mean having procedures in place for those maintainers to
make such branches as part of preparing a release and the pretest.

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

I hope this could be much more seamless, see below.

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

That's something we should resolve as part of the ELPA integration.

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

I don't agree.  We should have a reasonably comprehensive solution in
place, and it cannot just include building the tarball.  The solution
doesn't have to be perfect, but it should exist for all of the aspects
I mention below, and maybe some more.

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

That was a mistake, and this thread started as an attempt to fix it.

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

AFAICT, it depends whom you are asking.

Here's what I think we should have working to start bundling ELPA
packages:

 1. Git

    We need to have the bundled ELPA packages in the Emacs Git tree,
    and we should have an easy way of cloning/updating from upstream
    in a way that will also update the packages from ELPA.

    This should be set up in a way that both master and the release
    branch get updates from designated branches of the ELPA package's
    repository.  This way, working with the Emacs Git repository will
    remain almost unchanged.  Building Emacs from Git, something I at
    least do all the time, will also remain unchanged.

    (Yes, "git submodule" commands can do most or all of the above,
    and I think we should use them.)

    Package maintainers will have to provide designated branches with
    uniform names that will serve for fetching the package into each
    branch of the Emacs repository.

    One thing that will constitute a change is that each bundled
    package will need to have its own subdirectory of lisp/, even if
    the package is just one .el file.  Not a catastrophe, I think.

    Another aspect to consider is the auxiliary files -- README,
    documentation, etc. -- which come with the package.  We will need
    some changes in the Makefile's to have the products in the right
    places.

 2. Tarball

    Given that the Git repository will be ready due to the above, the
    procedures for creating a tarball will also remain almost
    unchanged.

 3. Users

    We need a clear picture of how this Emacs will be installed and
    used, both when installed from a distro and when built locally
    from the source tarball.  Maybe there's nothing to discuss here,
    but I at least don't yet have such a clear picture.  It should be
    possible to install, upgrade, and downgrade such packages, as much
    as possible using the same package.el commands as for unbundled
    packages.  As a minimum, AFAIU we will need to provide a directory
    in the tarball/installation that will have the same role as
    ~/.emacs.d/elpa/, because a tarball cannot possibly install files
    in the users' home directories.

I hope we can discuss each of these aspects (and others, if I missed
something), and this time actually come to a consensus and implement
that.