* In Support of ELPA @ 2017-07-11 21:46 Phillip Lord 2017-07-11 22:37 ` Stefan Monnier 0 siblings, 1 reply; 14+ messages in thread From: Phillip Lord @ 2017-07-11 21:46 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: In Support of ELPA 2017-07-11 21:46 In Support of ELPA Phillip Lord @ 2017-07-11 22:37 ` Stefan Monnier 2017-07-12 13:30 ` Ted Zlatanov 2017-07-13 16:15 ` Phillip Lord 0 siblings, 2 replies; 14+ messages in thread From: Stefan Monnier @ 2017-07-11 22:37 UTC (permalink / raw To: emacs-devel > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: In Support of ELPA 2017-07-11 22:37 ` Stefan Monnier @ 2017-07-12 13:30 ` Ted Zlatanov 2017-07-13 12:23 ` Richard Stallman 2017-07-13 16:15 ` Phillip Lord 1 sibling, 1 reply; 14+ messages in thread From: Ted Zlatanov @ 2017-07-12 13:30 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: In Support of ELPA 2017-07-12 13:30 ` Ted Zlatanov @ 2017-07-13 12:23 ` Richard Stallman 2017-07-13 15:05 ` Ted Zlatanov 0 siblings, 1 reply; 14+ messages in thread From: Richard Stallman @ 2017-07-13 12:23 UTC (permalink / raw To: Ted Zlatanov; +Cc: emacs-devel [[[ 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: In Support of ELPA 2017-07-13 12:23 ` Richard Stallman @ 2017-07-13 15:05 ` Ted Zlatanov 2017-07-13 22:02 ` Phillip Lord 0 siblings, 1 reply; 14+ messages in thread From: Ted Zlatanov @ 2017-07-13 15:05 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: In Support of ELPA 2017-07-13 15:05 ` Ted Zlatanov @ 2017-07-13 22:02 ` Phillip Lord 0 siblings, 0 replies; 14+ messages in thread From: Phillip Lord @ 2017-07-13 22:02 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: In Support of ELPA 2017-07-11 22:37 ` Stefan Monnier 2017-07-12 13:30 ` Ted Zlatanov @ 2017-07-13 16:15 ` Phillip Lord 2017-07-14 1:20 ` Richard Stallman 2017-07-14 2:12 ` Stefan Monnier 1 sibling, 2 replies; 14+ messages in thread From: Phillip Lord @ 2017-07-13 16:15 UTC (permalink / raw To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: In Support of ELPA 2017-07-13 16:15 ` Phillip Lord @ 2017-07-14 1:20 ` Richard Stallman 2017-07-14 10:02 ` Phillip Lord 2017-07-14 2:12 ` Stefan Monnier 1 sibling, 1 reply; 14+ messages in thread From: Richard Stallman @ 2017-07-14 1:20 UTC (permalink / raw To: Phillip Lord; +Cc: monnier, emacs-devel [[[ 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: In Support of ELPA 2017-07-14 1:20 ` Richard Stallman @ 2017-07-14 10:02 ` Phillip Lord 2017-07-16 1:50 ` Richard Stallman 0 siblings, 1 reply; 14+ messages in thread From: Phillip Lord @ 2017-07-14 10:02 UTC (permalink / raw To: Richard Stallman; +Cc: monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: In Support of ELPA 2017-07-14 10:02 ` Phillip Lord @ 2017-07-16 1:50 ` Richard Stallman 2017-07-17 14:05 ` Phillip Lord 0 siblings, 1 reply; 14+ messages in thread From: Richard Stallman @ 2017-07-16 1:50 UTC (permalink / raw To: Phillip Lord; +Cc: monnier, emacs-devel [[[ 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: In Support of ELPA 2017-07-16 1:50 ` Richard Stallman @ 2017-07-17 14:05 ` Phillip Lord 0 siblings, 0 replies; 14+ messages in thread From: Phillip Lord @ 2017-07-17 14:05 UTC (permalink / raw To: Richard Stallman; +Cc: monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: In Support of ELPA 2017-07-13 16:15 ` Phillip Lord 2017-07-14 1:20 ` Richard Stallman @ 2017-07-14 2:12 ` Stefan Monnier 2017-07-14 6:48 ` Thien-Thi Nguyen 1 sibling, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2017-07-14 2:12 UTC (permalink / raw To: Phillip Lord; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: In Support of ELPA 2017-07-14 2:12 ` Stefan Monnier @ 2017-07-14 6:48 ` Thien-Thi Nguyen 2017-07-15 1:35 ` Richard Stallman 0 siblings, 1 reply; 14+ messages in thread From: Thien-Thi Nguyen @ 2017-07-14 6:48 UTC (permalink / raw To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: In Support of ELPA 2017-07-14 6:48 ` Thien-Thi Nguyen @ 2017-07-15 1:35 ` Richard Stallman 0 siblings, 0 replies; 14+ messages in thread From: Richard Stallman @ 2017-07-15 1:35 UTC (permalink / raw To: emacs-devel [[[ 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2017-07-17 14:05 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-07-11 21:46 In Support of ELPA Phillip Lord 2017-07-11 22:37 ` Stefan Monnier 2017-07-12 13:30 ` Ted Zlatanov 2017-07-13 12:23 ` Richard Stallman 2017-07-13 15:05 ` Ted Zlatanov 2017-07-13 22:02 ` Phillip Lord 2017-07-13 16:15 ` Phillip Lord 2017-07-14 1:20 ` Richard Stallman 2017-07-14 10:02 ` Phillip Lord 2017-07-16 1:50 ` Richard Stallman 2017-07-17 14:05 ` Phillip Lord 2017-07-14 2:12 ` Stefan Monnier 2017-07-14 6:48 ` Thien-Thi Nguyen 2017-07-15 1:35 ` Richard Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.