() 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