Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

[Dmitry Gutov]

On 18.05.2020 06:49, Richard Stallman wrote:
> [[[ 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. ]]]
>
>    > I'd say it all depends. We probably aren't going to simply follow what
>    > the author will be asking for, either.
>
>    > Do they want code review? We could do it once (couldn't we?), but if the
>    > author wants all the changes reviewed all the time, we would probably do
>    > that only for most important packages. Ones that will be enabled for
>    > default, maybe?
>
> If we are going to continue saying, of GNU ELPA, that "You can trust
> it", I think that we need to do some code review for every package in
> GNU ELPA.  We had better treat serious bugs in GNU ELPA the way we
> treat serious bugs in Emacs.

I'm all for it, personally. As far as I know, this has only been limited 
by our developers' free time (or its deficit), and by their general 
disinterest (seems like).

I don't think any package author would really object to an external 
review, people pointing out serious bugs, etc.

(Enforcing commit message format and documentation standards are a 
somewhat different matter.)

> If we want to have two different ways of treating those packages,
> we need to show the users which category each package is in.
>
> The reliable way to do that is to have two archives: one we say you
> can trust, and one that provides only a place to distribute them.

Personally, I don't know if we really need two archives, or packages we 
don't "trust". We could somehow annotate packages without copyright 
assignment, but its lack alone doesn't make a package untrustworthy.

> Good names might be "GNU Emacs Exocore" for the ones we review, and
> "GNU ELPA" for those we don't.  I suggest "Exocore" as meaning "like
> the core, but hosted separately."
>
> Or maybe, GNU ELPA for the ones we review, and Alt-ELPA for what we don't.
>
> For now, let's call them reviewed and unreviewed.

We still could do that, if we find that we don't have enough manpower 
for reviewing all.

> MAYBE it will work well if we get papers for the reviewed packages
> but not for the unreviewed.  Then the reviewed packages might be
> merged into the core, and the unreviewed are ones we don't consider
> moving into the core.  So if we think a package might be good to put
> in the core, we should review it AND get papers for it.

Not sure this would be best for the users, but it does make some 
economical sense.