From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: In Support of ELPA Date: Fri, 14 Jul 2017 08:48:56 +0200 Message-ID: <87mv87a4yv.fsf@zigzag> References: <87eftmejer.fsf@russet.org.uk> <87wp7ccnz6.fsf@russet.org.uk> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: blaine.gmane.org 1500015046 15293 195.159.176.226 (14 Jul 2017 06:50:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Jul 2017 06:50:46 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 14 08:50:40 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dVuQs-0003KB-OD for ged-emacs-devel@m.gmane.org; Fri, 14 Jul 2017 08:50:34 +0200 Original-Received: from localhost ([::1]:35836 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVuQy-0006aI-71 for ged-emacs-devel@m.gmane.org; Fri, 14 Jul 2017 02:50:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51460) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVuQL-0006Yo-93 for emacs-devel@gnu.org; Fri, 14 Jul 2017 02:50:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVuQH-00013l-B0 for emacs-devel@gnu.org; Fri, 14 Jul 2017 02:50:01 -0400 Original-Received: from mail.agora-net.com ([67.59.132.6]:55716) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dVuQH-00012x-5k for emacs-devel@gnu.org; Fri, 14 Jul 2017 02:49:57 -0400 Original-Received: from ttn by mail.agora-net.com with local (Exim 4.82) (envelope-from ) id 1dVuQF-00034H-SD for emacs-devel@gnu.org; Fri, 14 Jul 2017 02:49:55 -0400 Original-Received: from ttn by zigzag.favinet with local (Exim 4.80) (envelope-from ) id 1dVuPU-0007Gv-QH for emacs-devel@gnu.org; Fri, 14 Jul 2017 08:49:08 +0200 Mail-Followup-To: emacs-devel@gnu.org In-Reply-To: (Stefan Monnier's message of "Thu, 13 Jul 2017 22:12:38 -0400") X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ttn@gnuvola.org X-SA-Exim-Scanned: No (on mail.agora-net.com); SAEximRunCond expanded to false X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 67.59.132.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:216635 Archived-At: --=-=-= Content-Type: text/plain () Stefan Monnier () 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlloaVwACgkQZwMiJEyAdQItxgCZARgKF5Rea/NTwD5Gp5kpZR7T NQgAoJYp51gnFOKdPAAYYloVO4zlvBsP =SSQt -----END PGP SIGNATURE----- --=-=-=--