Re: New ELPA policy proposal (was: ELPA policy)

[Artur Malabarba]

2015-11-09 11:15 GMT+00:00 Oleh Krehel <address@hidden>:
> 1. Only packages which are relatively independent are allowed to be
> moved to ELPA. This is a rule that we adhere to right now, I just wanted
> to re-state it. And it's important for the next point.
>
> 2. Each package is developed it its own Git repository, and is included
> into the common ELPA directory as a Git submodule.  No actual code is
> ever committed into the Emacs git repository, only the commit hashes,
> when an ELPA package maintainer deems it appropriate to merge,

Two Things:

* The first and simplest issue here is that we would lose control over
the code on Gelpa.

We can still remove any package from Gelpa entirely, of course. But it
would be difficult for the Emacs maintainers to edit a package on
Gelpa that's doing something wrong. For instance, Stefan has edited
several of my packages in the past (which I'm grateful for), and he
wouldn't have been able to do that if the source wasn't on elpa.git.

But maybe that's just a cost that needs to be paid if we want Gelpa to scale.

* Another thing to remember is that we need to be able to trust that
code made available by Gelpa has been properly copyright assigned.

The current way we do that is to:
1. Only make available code that has been pushed to elpa.git.
2. We trust those with push access to only push code that's been
assigned (to the best of their knowledge).
3. We trust that those who submit code are not lying about its origins.

IIUC, your proposal is that new releases would be marked by editing a
file in the Gelpa repo and adding a hash of the relevant commit.
This sounds more or less ok:
2. The manual edit of a hash would still have to be done by people
with push access, so only they could ultimately make new code
available on Gelpa.
3. The act of a developer asking us to edit a hash could be considered
analogous to the act submitting a package (i.e., they are declaring
that all the new code in that commit has been properly assigned, just
like they originally declared so when first submitting the package).

> 3. On Emacs release, we'll have emacs.tar (for people with low
> bandwidth) and emacs-with-elpa.tar (the recommended download).

I'm perfectly in favor of this. And it's pretty much independent of
the points above. Of course, the inner workings of Gelpa affect how
the build-script might create this emacs-with-elpa.tar, but they don't
affect the feasibility or difficulty of this task.

So it's just a matter of someone writting the necessary
scripts/documentation for the next release.