Re: Improving GNU ELPA

[Phillip Lord]

Richard Stallman <address@hidden> writes:

> [[[ 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. ]]]
>
>   > As I said, it doesn't avoid the problem, it just changes the nature of
>   > that problem.
>
> I have a hunch that "the problem" you are talking about is not the
> same problem.  I can't verify this, because you tallk about "the
> problem" tersely in the abstract, without stating concretely what
> problem you mean.  But I am pretty sure it's not the one I am trying
> to avoid.

Specifically, that I cannot push to dash on github which is the main
repository. This is not a big deal, I just haven't asked for it.

>
>                 As Stefan has said, at the moment, dealing with these
>   > issues is, anyway, consider the problem of the upstream person.
>
> I would describe that as the "easy way out".  You consider it a good
> option and recommend it as a solution, but I see it as opening a can
> of worms.  Thus, for me it is "the problem" and I am looking for how
> we can _avoid_ it.
>
>   > The
>   > presence of push rights changes nothing if you do not use them.
>
> Alas, I don't follow -- that is rather terse, so I don't understand
> the point.  I am not sure whether I would agree or disagree, if I
> understood.


So, the issue is this:

Assume we have a package (like dash) which is maintained and developed
in some external git repo.

I think, ELPA would be easier to use if it just pulled directly and
automatically from this external git repo. If the Emacs maintainers want
to update that package, they should use PRs to the upstream. Commit or
push rights on upstream are not necessary. This is enough, for most
cases, and is also easy for the upstream developer. This is also how
MELPA runs, so clearly it can work in practice.

There are emergencies that we might concieve of where a change needs to
be made to ELPA immediately, today, without any delay. In these
circumstances, a copy of the project history would be available in the
ELPA repository. Changes could be made there, with the knowledge that
the upstream package would need to do something to reincorporate these
emergency changes. MELPA has a similar policy for switching upstream.

This requires almost no software (just something to run the pull), no
changes to ELPA, just a change in policy. In response, ELPA becomes a
little more frictionless, a little more convienient for contributors.

Going round in circles here, so I stop.

Phil