Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden,
>   address@hidden,  address@hidden,  address@hidden
> Date: Tue, 12 May 2020 15:50:52 -0400
> 
> > Do we have a mechanism to declare that a package is not intended to be
> > brought into core, unless changed to follow the same standards and
> > guidelines as the core does?
> 
> Being a GNU ELPA package does not mean "intends to be brought into core".
> Never has, never will.

Others seem to think otherwise.  So maybe we should begin even farther
back: by defining what it means to be a GNU ELPA package that is
considered "compatible with core".

Here's my definition: it is a package which we can move in or out of
core whenever we like, and/or distribute it as part of an Emacs
release, whether the Emacs source tarball or any auxiliary tarballs
that are considered part of an official Emacs distribution.

> > A package that is thus declared can then be exempt from some of the
> > requirements (we still need to agree on which ones, though).
> 
> If we only label those rare ones for which we do have plans to integrate
> them, we don't need to "agree first" since in case of disagreement the
> package just won't be integrated.

I think we do need to agree up front.  The reason is simple: a package
that will never be "core-compatible" is of no special interest to us.
When accepting it, we should only verify several simple
technicalities.  We don't need to pay any attention to later changes,
we don't need to check its sources for use of any deprecated APIs, we
don't need to be bothered by its documentation and by its being
consistent with the rest of our conventions -- because our code will
never directly call any of that package's APIs.  In effect, we are
just hosting the package in ELPA so that we could freely recommend it
to our users and to other 3rd-party packages, and make package.el
install it without any non-default configuration.

That is not so for packages that we would decide to keep "compatible".

> Personally I don't see much benefit in such labeling: the way I expect
> it to work is rather:
> - Shouldn't we include SuperFoo into the tarball?
> - Oh, yes, good idea.  Let's see ... is it in a good enough shape?
> - Almost, we just have to fix this and that.
> - OK, let's do that.
> - [time passes]
> - Alright, now this and that has been fixed, let's include it.
> - Great, thanks, done.
> No labeling involved.

This is not a good idea, IMO.  It would mean that deciding to include
a package in a tarball or even optionally call from our sources would
mean we need at that time to do all the review work we didn't before,
which is a much larger job.  More so if we are doing this with several
packages at once, due to their dependencies.  It is much easier to do
this piecemeal over many moons.

We would also need to ask the package developers to make all those
adjustments at once, and they could rightfully ask us why we suddenly
come up with all those requests when the package already happily lives
several years on ELPA in its present form.  It would be hard to come
up with a good answer to that.

So no, your proposal doesn't really work for me, sorry.