emacs-devel
[Top][All Lists]
Advanced

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

Re: NonGNU ELPA work


From: Bozhidar Batsov
Subject: Re: NonGNU ELPA work
Date: Sun, 02 Jan 2022 11:11:06 +0200
User-agent: Cyrus-JMAP/3.5.0-alpha0-4525-g8883000b21-fm-20211221.001-g8883000b

For what is worth - I also think we should keep the submission process as simple as possible if we want NonGNU ELPA to gain traction. Often packages would get submitted as deps of other packages (e.g. someone would submit a package that depends on 3 other packages that also need to be included on NonGNU ELPA) and I don't think we want to burden someone to chase down all the package authors just to get their OK. All you need is one unresponsive package author to block the inclusion of a potentially great package on NonGNU ELPA.

If something is a well structured package and it's licensed under GPL that's all we need IMO. After all NonGNU ELPA doesn't require maintainers to do anything special on their end, which means there's no real reason to contact them about it.

On Sun, Jan 2, 2022, at 10:15 AM, Eli Zaretskii wrote:
> From: Richard Stallman <rms@gnu.org>
> Cc: philipk@posteo.netstefankangas@gmail.comemacs-devel@gnu.org
> Date: Sun, 02 Jan 2022 02:01:37 -0500

>   > I don't think you said you agreed explicitly, but all of the concerns
>   > you described were addressed, and you didn't respond to the last
>   > messages in that discussion.

> That message from Sep 4 responded by my concerns by refusing to
> address them.

"Refusing to address" is a harsh and unfair characterization of what I
wrote there.

The message expressed surprise that there were significant additional
requirements for NonGNU ELPA where we don't have anything similar in
other cases when we accept code contributions.  And that is just the
summary: there were arguments and other issues raised in that exchange
which expanded on that.  If that's "refusal to address", then I don't
know what an agreement to address would look like.  Addressing your
concerns doesn't necessarily mean agreeing to everything you say.

> Why do we need special rules for NonGNU ELPA?  Because we are not
> applying the usual rules that we use to assure our legal needs and
> moral principles with everything else in Emacs.  For Emacs core and
> for GNU ELPA, we use copyright papers, and we notice and correct
> things that conflict with our principles.  But the point of NonGNU
> ELPA is to be an exception to those rules -- so we need another
> solution for it.

The only exception of NonGNU ELPA is the copyright papers, but I fail
to see how that affects the rest, i.e. noticing and correcting things
that conflict with our principles.  The copyright papers do nothing to
help in this regard.  We are required to do all that with any
contribution, whether to the core or to GNU ELPA.

>       https://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/README.org

> When the maintainers agreed to these rules a year ago, that was what
> convinced me that we could go ahead with NonGNU ELPA.  But we didn't
> set up a methodical system to carry them out.  We need that.

The agreement was under the assumption that we do all those jobs
anyway for any contribution, so no new system needs to be installed.
It turns out now you had something very different in mind.

What you request is a significant amount of additional clerical work
for reasons I at least don't yet understand completely.  And even if I
did understand them, there's still the non-trivial issue of finding
the volunteer(s) to do that job.




reply via email to

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