Re: Core ELPA was: Testing fontification, indentation, and buffer manipulation

[phillip.lord@russet.org.uk (Phillip Lord)]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The problem with branches is that what is on the branch changes. My
>> feeling is that the build process should be repeatable; so building
>> emacs-27.1-with-elpa.tgz should not result in different tar balls as
>> ELPA changes.
>
> By principle, GNU ELPA packages don't have to be "in-sync" with Emacs,
> so this is not terribly important.

I'm unconvinced. I think a build should be repeatable. Imagine bisecting
a bug that has come up in an ELPA package when you are not sure whether
it's the package or Emacs core that has broken things.

Of course, this makes continuous integration harder. The solution there
is, I think, to run "make test" on the ELPA repository against the
current Emacs build. This already runs on head of all branches I think.

> I think on Emacs `master` we won't want to use fixed SHAs but will just
> use whatever's on `master` of elpa.git.  On the release branch, we'll
> probably want to be more specific, using corresponding branches.

That might mean multiple branches of master which would produce a very
cluttered namespace. The problem is that ELPA currently uses a different
(non git) mechanism to identify the current version of every package; so
you can't identify this from git metadata (except for SHA!).


>> Finally, neither solve the problem -- if a branch or tag is add
>> EMACS/elpa/Makefile.in which exists in the ELPA repo, but not in the
>> clone on the local machine the build will fail.
>
> I think the use of branches/tags will make it sufficiently infrequent
> that it's not a big deal.  Also the build shouldn't completely fail.

Beyond removing the configure option, it will fail at the moment. I
could do something else beyond that. But surely, by default, the build
should fail, if something fails?

Phil