[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: In Support of ELPA
Re: In Support of ELPA
Fri, 14 Jul 2017 08:48:56 +0200
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)
() Stefan Monnier <address@hidden>
() 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
"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
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:
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
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
Description: PGP signature
Re: In Support of ELPA, Phillip Lord, 2017/07/13
Re: In Support of ELPA, Stefan Monnier, 2017/07/13
Re: In Support of ELPA,
Thien-Thi Nguyen <=
Re: In Support of ELPA, Richard Stallman, 2017/07/14
- Re: In Support of ELPA, (continued)