[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: In Support of ELPA
From: |
Phillip Lord |
Subject: |
Re: In Support of ELPA |
Date: |
Thu, 13 Jul 2017 23:02:26 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2.50 (gnu/linux) |
Ted Zlatanov <address@hidden> writes:
>>> Can GnuPG signatures satisfy that requirement so the code can be pulled?
>
> RS> The question is so vague that I can't relate it to the issue at hand.
> RS> GPG signatures delivered by whom, when, signing what, to achieve what
> RS> purpose?
>
> Sorry for the vagueness.
>
> I mean that maintainers of packages can use GnuPG signatures in Git to
> sign a particular tag.
If we trust someone to sign a tag, why not just trust them not to merge
code into upstream?
> So maybe that's enough to let the GNU ELPA pull instead of requiring
> maintainers to push, because the signature will guarantee that the
> code has been reviewed for copyright and other requirements. The
> verification can be automated.
Simply having a list of assignees and their aliases to achieve
approximately the same thing.
> I think a pull-based system like that would reduce friction and increase
> contributions, because maintainers won't have to get access to elpa.git
> or push anything. They would just do a release tag as part of their
> normal workflow.
Yep. Compare MELPA and marmalade. (Side-track) I tend to agree with Nic
Ferriers concerns about emacs packages (end side-track). The fantastic
ease of use of MELPA (i.e. set it up, then do nothing that you are not
doing anyway) is a big reason for its success.
Phil
- In Support of ELPA, Phillip Lord, 2017/07/11
- Re: In Support of ELPA, Phillip Lord, 2017/07/13
- Re: In Support of ELPA, Stefan Monnier, 2017/07/13
- Re: In Support of ELPA, Thien-Thi Nguyen, 2017/07/14
- Re: In Support of ELPA, Richard Stallman, 2017/07/14