Re: New ELPA policy proposal

[Oleh Krehel]

Artur Malabarba <address@hidden> writes:

> 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.

This doesn't have to be so. GELPA is a git repository on
Savannah. Anyone with proper SSH keys can edit it.  What I propose is to
split GELPA into 130 git repositories on Savannah (or separate git
branches of one repository if that's more convenient).  All Emacs devs
will still have the same access to every package. But the commit log
won't be a mingled mess: each package will have its own commit log and
its own version - the latest version tag on the appropriate branch.
Then the main ELPA directory will hold the current version hashes for
each ELPA package. And the main Emacs repository will hold one ELPA hash
snapshot for each Emacs release.

> * 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).

I assume the process could have several tiers.

tier 1: I edit my package in a Git repository on my machine and accept
contributions with CA.

tier 2: I sync my Git repository with its Git repository on Savannah (a
    sub-directory of GELPA)

tier 3: The main directory of GELPA should always hold the hashes
     of all packages, the stable versions that are to be published to
     https://elpa.gnu.org/packages/. This information will be updated
     with each new release of any package.

tier 4: On release of a new Emacs version, a snapshot of GELPA hashes
    will be committed into Emacs. All code that corresponds to that
    snapshot will be bundled with emacs-with-elpa.tar.

Currently, tier 3 is done with ";; Version: ..." cookie. I propose that
we do it with git tags and hashes instead/additionally.
As for tier 4, the package maintainers take the responsibility to ensure
that the package hash included into Emacs works correctly around the time
when each feature freeze is announced.

The above system can solve an inconvenience that I've occasionally run
into with the current GELPA setup: the "git subtree merge" doesn't allow
me to easily pull anyone's changes done in GELPA back into my package.
In fact, at times I haven't noticed a change for a month, committed a
bunch on top of the version in GELPA, and then had to do a rebase and
resolve merge conflicts.

In the end, I'd like to setup a workflow where my package has two
identical public fronts: one on Github and one on Savannah. Pushing to
one should push to the other one.  And if I pull from both, I'll be
immediately notified if any other Emacs developer edited my package on
Savannah, and I'll just commit on top of these changes.

Here's a visual representation of the ELPA directory on Savannah that I
propose:

|-elpa/
|--.git/
|--ace-window/
|---./git/
|--ack/
|---.git/
...
|--.gitignore
|--package-list

Everyone that currently has access to ./elpa/ will automatically have
access to ./elpa/*.
Each sub-directory is its own git repository, and ./.gitignore will ignore
everything except ./package-list, and maybe some auxiliary scripts.

./package-list could have the following structure:

    ace-window: eef897e590c4ce63c28fd29ebff3c97aec8a69ae
    ack: 1487ae155ccc2a3099b8e0f20334a79fa8f5b9a8
    ...

In the end, ./package-list could simply be built automatically by a
shell command examining each repository for a version tag.  But it might
be good to have each new version release accompanied by a commit to
./package-list.