In Support of ELPA

In Support of ELPA

[Phillip Lord]

Following on from the emails about magit, I am going to have a go at
getting copyright assignments for it, so that it can be included in
either ELPA or Emacs.

I've already discussed the pain points with the copyright assignment,
but an additional issue is how to get code into ELPA. With dash.el, I
added the dash repo as an "external" branch into ELPA.

I think, though, this is still a bit clunky. I think it would be nice to
add support for MELPA recipes directly in ELPA. This was adding an MELPA
package to ELPA would require simply copying the recipe from MELPA.

Assuming we support only MELPAs git (and github maybe) recipes, this
could be done by either creating a new external branch for ELPA, or
updating an existing branch from downstream. This functionality fits
directly on topic of the existing ELPA code.

Anyone have thoughts? And would any one be interested on adding it, as I
will struggle to do this as well as working on assignments.

Phil

Re: In Support of ELPA

[Stefan Monnier]

> I think, though, this is still a bit clunky. I think it would be nice to
> add support for MELPA recipes directly in ELPA. This was adding an MELPA
> package to ELPA would require simply copying the recipe from MELPA.

I find it is important for GNU ELPA not to *pull* from outside hosts
that are not under our control.  Instead code should be pushed to it by
people who have write access (hence take on the responsibility of paying
attention to copyright and such).


        Stefan

Re: In Support of ELPA

[Ted Zlatanov]

On Tue, 11 Jul 2017 18:37:18 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> I find it is important for GNU ELPA not to *pull* from outside hosts
SM> that are not under our control.  Instead code should be pushed to it by
SM> people who have write access (hence take on the responsibility of paying
SM> attention to copyright and such).

Can GnuPG signatures satisfy that requirement so the code can be pulled?

Ted

Re: In Support of ELPA

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > SM> I find it is important for GNU ELPA not to *pull* from outside hosts
  > SM> that are not under our control.  Instead code should be pushed to it by
  > SM> people who have write access (hence take on the responsibility of paying
  > SM> attention to copyright and such).

  > Can GnuPG signatures satisfy that requirement so the code can be pulled?

The question is so vague that I can't relate it to the issue at hand.
GPG signatures delivered by whom, when, signing what, to achieve what
purpose?

But I am pretty sure the answer that GPG is irrelevant to this issue.
This is not about getting a signature (GPG signatures are usable in
the US and Italy), it is about a relationship with a person who we
trust to assure certain things are done right.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In Support of ELPA

[Ted Zlatanov]

On Thu, 13 Jul 2017 08:23:27 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
RS> [[[ whether defending the US Constitution against all enemies,     ]]]
RS> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

SM> I find it is important for GNU ELPA not to *pull* from outside hosts
SM> that are not under our control.  Instead code should be pushed to it by
SM> people who have write access (hence take on the responsibility of paying
SM> attention to copyright and such).

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

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.

Ted

Re: In Support of ELPA

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I think, though, this is still a bit clunky. I think it would be nice to
>> add support for MELPA recipes directly in ELPA. This was adding an MELPA
>> package to ELPA would require simply copying the recipe from MELPA.
>
> I find it is important for GNU ELPA not to *pull* from outside hosts
> that are not under our control.  Instead code should be pushed to it by
> people who have write access (hence take on the responsibility of paying
> attention to copyright and such).


If the outside host is someone who has write access to ELPA does it make
any difference? It's just a different way of trusting people.

Ultimately, pull requests of this form would result in emails going to
the ELPA-diffs mailing list, so we'd be able to check there. And, if we
can get the people who have assigned copyright as a CSV along with their
aliases, you could check the commit messages on the way through for
authorship.

Phil

Re: In Support of ELPA

[Phillip Lord]

Ted Zlatanov <tzz@lifelogs.com> 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

Re: In Support of ELPA

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > If the outside host is someone who has write access to ELPA does it make
  > any difference?

The difference is whether the Emacs maintainers have write access
to those sources in their main repository.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In Support of ELPA

[Stefan Monnier]

> If the outside host is someone who has write access to ELPA does it make
> any difference? It's just a different way of trusting people.

"The outside host" is a machine, it's not a "someone".
"has write access" is a property which can change over time.  So unless
we have some process or someone watching over those changes "had write
access when we added the package" will often turn into some rather
irrelevant historical data,

> Ultimately, pull requests of this form would result in emails going to
> the ELPA-diffs mailing list, so we'd be able to check there. And, if we
> can get the people who have assigned copyright as a CSV along with their
> aliases, you could check the commit messages on the way through for
> authorship.

"git push elpa" is not that hard either.


        Stefan

Re: In Support of ELPA

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 3618 bytes --]


() Stefan Monnier <monnier@IRO.UMontreal.CA>
() Thu, 13 Jul 2017 22:12:38 -0400

   > If the outside host is someone who has write access to ELPA
   > does it make any difference? It's just a different way of
   > trusting people.

   "The outside host" is a machine, it's not a "someone".  "has
   write access" is a property which can change over time.  So
   unless we have some process or someone watching over those
   changes "had write access when we added the package" will
   often turn into some rather irrelevant historical data,

   > Ultimately, pull requests of this form would result in
   > emails going to the ELPA-diffs mailing list, so we'd be
   > able to check there. And, if we can get the people who have
   > assigned copyright as a CSV along with their aliases, you
   > could check the commit messages on the way through for
   > authorship.

   "git push elpa" is not that hard either.

First, my understanding (additions/corrections welcome):

If the outside repo "goes bad" for some reason, how we prevent
that badness from entering ELPA (pull vs push) only matters if
the gating (acceptance criteria and mechanisms) differs.

At present, once a package is initially accepted, there is no
further meaningful gating AFAICT, so there is no difference at
that level.  The difference lies in convenience, mostly.

Feature-wise, (set-difference ELPA MELPA) => accountability; we
require proper licensing practice and copyright assignment.  So
"meaningful gating" is essentially verification that a package's
initial accountability is maintained for old files, and proper
for new.

Next, "my" proposal (not really original, but a rephrasing of
what various people have been saying here and there):

(a) Make the accountability database format machine-friendly.
    Publish the format details.

(b) Write (or find) a program to maintain the database, i.e.,
    all reads/writes go through this program.  It should be able
    to work locally on a database subset (w/o Net).

(c) Write a program to determine a package's accountability.
    Its output is the package's "accountability state", as well
    as an audit (and debugging :-D) trail of how that state was
    determined.  IOW, both what and why.

(d) Write a program to "diff" two accountability states (bonus
    points if it handles the why, as well).

(e) Write some git-hooks(1) scripts that DTRT:
    - pre-push
    - update
    DTRT is "gate" or "gate verbosely" based on accountability.
    These use the above-defined programs and a local subset of
    the accountability database.

(f) Update the admin script(s) to gate pull on accountabilty.

(g) Update README to prominently describe accountability
    requirements and maintenance.

(h) Set up ELPA on the GNU GitLab instance.

(i) Like (e), but deployable as part of GitLab CI.

Of these, (a) through (e) are largely mechanism, and depending
on programmer foresight, might yield fruit for GNU in general;
(f) and (g) touch on policy; (h) and (i) relate to scaling.

Now, to the nitty gritty: what can/will i *do*?  Well, if/when i
overcome my fear of javascript (and the surveillance state, in
general), i can set up a GitLab project, invite others to join,
and do high-level manglement.  OTOH, if such a project already
exists, maybe i can join that, instead.  What am i missing?

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)
   (pcase (context query)
     (`(technical ,ml) (correctp ml))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: In Support of ELPA

[Phillip Lord]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > If the outside host is someone who has write access to ELPA does it make
>   > any difference?
>
> The difference is whether the Emacs maintainers have write access
> to those sources in their main repository.

Personally, I think this is not necessary. The Emacs maintainers can use
PRs if they need to.

Ultimately, if we accept the notion of a "downstream" it's far easier to
make all changes there, rather than have to manage changes from two
places. The ELPA repo isn't really set up well for development: it has a
large number of independent projects in one place, and uses branches for
something else.

Reducing the friction of ELPA would include removing the necessity for
changing the version control practices of existing projects.

Phil

Re: In Support of ELPA

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > If the outside repo "goes bad" for some reason, how we prevent
  > that badness from entering ELPA (pull vs push) only matters if
  > the gating (acceptance criteria and mechanisms) differs.

Please see the messages I posted about why we need administrative
control over the base repository.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In Support of ELPA

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > The difference is whether the Emacs maintainers have write access
  > > to those sources in their main repository.

  > Personally, I think this is not necessary. The Emacs maintainers can use
  > PRs if they need to.

We need to have write access directly so that we can install changes
directly without depending on anyone else.  But not solely write access.
We need administrative access too.  When other people send PRs, we need
to be able to receive them.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: In Support of ELPA

[Phillip Lord]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > The difference is whether the Emacs maintainers have write access
>   > > to those sources in their main repository.
>
>   > Personally, I think this is not necessary. The Emacs maintainers can use
>   > PRs if they need to.
>
> We need to have write access directly so that we can install changes
> directly without depending on anyone else.  But not solely write access.
> We need administrative access too.  When other people send PRs, we need
> to be able to receive them.

I don't think this is necessary, not with a distributed version control
system. If we have a package developed elsewhere, and ELPA has a local
clone (either as a repo, or a branch), then any PRs from others could be
resent to the downstream, and likewise any changes for Emacs
maintainers.

On the occasion that a change really needs to be installed locally
without depending on any one else, then you could just do
this. Subsequent pulls from downstream to ELPA would now fail, as they
would be non-fast-forward; someone would have to sort this out
manually. But this is the situation anyway, if there is a downstream
copy of the source code; changes made on ELPA have to be incorporated
back into the mainline.

What sort of changes do you envisage where a PR is not enough? How often
do these happen?

Phil