unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 59609@debbugs.gnu.org, stefankangas@gmail.com
Subject: bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual
Date: Fri, 08 Sep 2023 16:10:38 -0400	[thread overview]
Message-ID: <jwv8r9gbfzv.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83a5twwmaq.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 08 Sep 2023 21:29:49 +0300")

>> FWIW, GNU ELPA packages don't necessarily "adhere to the Emacs coding
>> conventions" either and neither are they all "supervised by the Emacs
>> maintainers" or "have to coordinate their development decisions with the
>> Emacs team".  Some do, but not all of them by a long shot.
>
> Only because we decide not to do that, or are lazy, or whatever.
> Basically, it's our decision for GNU ELPA, and not so for NonGNU ELPA.

We have just as much control in one as in the other, in practice.
Maybe we tend to invest more efforts in the GNU part, but I'd argue that
it's not "because it's in GNU" but because there is a positive
correlation between people agreeing to assign their copyright and people
sharing our goals.

>> In practice the real deciding factor *is* the copyright assignment
>> (which often ends up selecting for a kind of "philosophical agreement"
>> about the primacy of ethical goals over technical ones).
> I think this is just the tip of a very large iceberg, and the FAQ
> should say that explicitly.

When I said:

    In practice the real deciding factor *is* the copyright assignment

I really meant that this is usually the only factor that makes me decide
whether to add a package to GNU or to NonGNU.
I can't speak for Philip, but I have the impression he does the same.

> Saying that just the CA is the difference is both very inaccurate and
> misrepresents the actual situation: NonGNU ELPA is a collection of
> packages that someone else decided could be useful, but we basically
> have nothing to do with them except hosting them.

"someone else"?  Packages are added there by "us":

    % git log -- elpa-packages| grep Author: | sort | uniq -c | sort -n
          1 Author: Alfred M. Szmidt <ams@gnu.org>
          1 Author: Bastien <bzg@gnu.org>
          1 Author: Bozhidar Batsov <bozhidar@batsov.com>
          1 Author: Bozhidar Batsov <bozhidar@batsov.dev>
          1 Author: Daniel Mendler <mail@daniel-mendler.de>
          1 Author: Danny Freeman <danny@dfreeman.email>
          1 Author: Distopico <distopico@riseup.net>
          1 Author: Dmitry Gutov <dgutov@yandex.ru>
          1 Author: Joseph Turner <joseph@ushin.org>
          1 Author: Sean Whitton <spwhitton@spwhitton.name>
          1 Author: Tassilo Horn <tsdh@gnu.org>
          1 Author: yilkalargaw <yilkalargawworkneh@gmail.com>
          3 Author: Daniel Semyonov <daniel@dsemy.com>
          3 Author: Eshel Yaron <me@eshelyaron.com>
          7 Author: Jonas Bernoulli <jonas@bernoul.li>
         15 Author: Akib Azmain Turja <akib@disroot.org>
         18 Author: Stefan Kangas <stefankangas@gmail.com>
         49 Author: Stefan Kangas <stefan@marxist.se>
         49 Author: Stefan Monnier <monnier@iro.umontreal.ca>
         87 Author: Philip Kaludercic <philipk@posteo.net>
    %

The result is not really different for `elpa.git`.  Several NonGNU
packages are (co)maintained by "us" (i.e. people who are regular
contributors to Emacs) and on the flip side, there are many GNU ELPA
packages for which "we basically have nothing to do with them except
hosting them".

I don't deny that there are other statistically qualitative differences
between GNU and NonGNU, but I think they're very fuzzy and to a large
extent they can be seen as a consequence of the copyright paperwork
(which makes it possible to imagine the package as being part of Emacs,
for example, thus justifying their presence in Debbugs).


        Stefan






  parent reply	other threads:[~2023-09-08 20:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-26 13:44 bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual Stefan Kangas
2022-11-26 14:20 ` Eli Zaretskii
2023-09-08 11:25   ` Stefan Kangas
2023-09-08 11:56     ` Eli Zaretskii
2023-09-08 15:04       ` Stefan Kangas
2023-09-11  0:40         ` Richard Stallman
2023-09-11  2:49           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-08 15:47       ` Drew Adams
2023-09-08 16:43       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-08 18:29         ` Eli Zaretskii
2023-09-08 18:47           ` Michael Albinus
2023-09-08 20:10           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-09-11  0:40             ` Richard Stallman
2022-11-27 22:54 ` Richard Stallman
2022-11-30 23:54 ` Richard Stallman
2022-12-01  3:49   ` Stefan Kangas
2022-12-03 23:40     ` Richard Stallman
2022-12-04  0:00       ` Stefan Kangas
2022-12-14 22:20         ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv8r9gbfzv.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=59609@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).