all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Thien-Thi Nguyen <ttn@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: In Support of ELPA
Date: Fri, 14 Jul 2017 08:48:56 +0200	[thread overview]
Message-ID: <87mv87a4yv.fsf@zigzag> (raw)
In-Reply-To: <jwv60evdb3p.fsf-monnier+Inbox@gnu.org> (Stefan Monnier's message of "Thu, 13 Jul 2017 22:12:38 -0400")

[-- 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 --]

  reply	other threads:[~2017-07-14  6:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2017-07-15  1:35         ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mv87a4yv.fsf@zigzag \
    --to=ttn@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.