Re: PL support

[Dmitry Gutov <dgutov@yandex.ru>]

On 11.05.2020 19:40, Eli Zaretskii wrote:
> If by "we" you mean the Emacs project, then we don't actually have a
> common shared view of this.  You evidently want to keep most of the
> packages on ELPA, and maybe even move out to ELPA packages already in
> core.  My opinion is almost the exact opposite, Stefan is in-between
> (perhaps closer to your opinion than to mine), and there are a
> plethora of other opinions.  these differences of opinion between us
> are well known, and we are still debating.

Seems so.

> We can maybe "track" them in the sense that we will know that
> copyright assignments are not being collected for certain packages,
> but in practice this makes it impossible to ever include such
> packages,

Probably, yes.

> because getting the legal papers signed many moons after the
> contribution becomes harder and harder as time passes.  We have live
> examples of such difficulties, and had a lot of them in the past.

We have examples of such difficulties when getting a package into the 
ELPA archive. Many of them. Out of those, I believe we would only 
consider incorporating a single-digit number of packages into "vanilla" 
Emacs. In the meantime, we're losing out on nearly-built-in support for 
many file types, e.g. yaml-mode.

> Given that the proposal is not to ask for copyright assignment, the
> coding standards are already "not imposed" but only "recommended"
> (read: waived),

Copyright assignment is an organizational standard, rather. But 
honestly, yes, it's difficult for us to impose hard coding standards. 
MELPA admins are doing this much more effectively, being #1 popular 
package repository.

I *would* support some sort of choosing criteria why we would want to 
accept some packages but not others, but "follows Emacs coding standards 
to a T" is unlikely to work. Or be useful, really.

> and Stefan and others seem to say that even cleanness
> of design and implementation and compatibility with the overall Emacs
> design are out of our hands, I really fail to see what would be the
> meaning of "vetted by us" in this context.

One obvious thing: every package is highly unlikely to nuke your 
machine, or steal your credentials. We can vet package releases, at 
least to some extent. MELPA admins can't do that, they don't have enough 
manpower or technical ability, given that they build every update of 
every package as soon as it hits the repository. Not even waiting for 
version bumps.

> That "us" is certainly not
> the Emacs project.  To me, it sounds like we are being asked to open a
> MELPA clone, which makes no sense to me.

We could also have other differentiating features. For example, asking 
authors of "external" packages to sign commits that bump the version number.