[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PL support

From: Dmitry Gutov
Subject: Re: PL support
Date: Mon, 11 May 2020 19:54:29 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]