Re: ELPA policy

[Stephen Leake]

address@hidden (Phillip Lord) writes:

> John Wiegley <address@hidden> writes:
>
>>>>>>> Richard Stallman <address@hidden> writes:
>>
>>> If a package is useful to recommend, and we CAN get papers for it, we
>>> definitely want to move it to GNU ELPA.
>>
>> Yes, this is why I want to clearly define ELPA policy, and streamline things
>> as much as possible for developers and users: so that it becomes a more
>> attractive means for distributing Emacs packages. I think many people may be
>> largely ignoring it right now, and so they reach for MELPA. Since so many
>> people contribute to MELPA, they consider it a more attractive distribution
>> platform.
>
>
> MELPA is also *easier* to contribute to. Aside from copyright issues, it
> involves writing something that looks like lisp, testing on your local
> fork, then a PR.
>
> With GNU ELPA, it involves some fairly obscure git cleverness. 

It's only normal git cleverness; there's nothing special about the Gnu
ELPA git. Unless you are using an "external" package, perhaps.

I can understand treating all of git as "obscure", if that's what you
meant. I much prefer monotone.

> GNU ELPA could be made easier by allowing recipes, and by accepting
> PRs. This avoids the necessity to have commit access to GNU ELPA to
> contribute.

"PR" is "Pull Request"? Doesn't that mean "pull from my git repository"?
Or is it more general than that?

> Finally, I think that core devs should contribute to individual packages
> by PR to their repos.

I'm guessing "their repos" is _not_ Gnu ELPA git? So this only applies
to packages that have a primary repo that is not Gnu ELPA git.

I agree that any one that edits a Gnu ELPA package in Gnu ELPA git
should also notify the upstream project if there is one. But they do not
have to wait for approval if it's a critical bug.

Normal ettiquette should apply of course.

This is more important for tarball and core ELPA packages, since they
are part of the blessed Emacs standard library; Emacs developers can
edit those as if they were in core.

-- 
-- Stephe