emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why are so many great packages not trying to get included in GNU Ema


From: Eric Abrahamsen
Subject: Re: Why are so many great packages not trying to get included in GNU Emacs?
Date: Fri, 24 Apr 2020 20:55:54 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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. ]]]
>
>   > I think it could be even simpler than that: ELPA is built every 24 hours
>   > right now. If we just registered external repos with ELPA, part of the
>   > build process could be pulling from those repos automatically
>
> That is rather breathless, so I can't concretely understand the
> proposal.  I can't start to think about what specific consequences it
> might have.  I am not sure which situations you propose to use this
> solution for.
>
> If this is meant as a way to implement pull requests, there is no need
> for it.  We will not implement pull requests by copying proposed
> patches into our repo before they are installed.
>
> There are various ways to implement pull requests.  The way I hope we
> will do it is that maintainers can ask to see the contents of the
> request, and commit it to our repo if/when that is proper.  Until that
> time, the patch won't be in our repo at all.
>
> Or maybe you're proposing a way to make a given package in GNU ELPA
> virtually included from some other GNU-managed repository; the method
> consisting of copying each commit automatically from that other repo
> to the GNU ELPA repo.

Yes, it's this latter I was referring to -- I don't have much feeling
about pull requests either way.

> It is ok to do that, assuming the other repo is managed appropriately,
> and your method could do it.  Other methods could give equivalent
> results.  We could use whichever method is most convenient.
>
> The crucial thing is that the repo where the package is really maintained
> be managed carefully in regard to who can commit changes.

And this was ultimately Stefan's concern, and the reason why my
suggestion is probably no-go. But no matter!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]