bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 214 bytes --]

Severity: wishlist

See the attached patch, which advertises (Non-)GNU ELPA a bit more in
the manual.  This would help make those archives more well-known and
attractive to users and package developers.

Thoughts?

[-- Attachment #2: 0001-Advertise-Non-GNU-ELPA-more.patch --]
[-- Type: text/x-diff, Size: 1183 bytes --]

From a90b8e5174b6bda548c08d1ce1f11b65fc564e60 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefankangas@gmail.com>
Date: Sat, 26 Nov 2022 14:39:03 +0100
Subject: [PATCH] Advertise (Non-)GNU ELPA more

* doc/emacs/package.texi (Packages): Advertise (Non-)GNU ELPA
more.
---
 doc/emacs/package.texi | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/doc/emacs/package.texi b/doc/emacs/package.texi
index cd4c113ae5..cdc5b3dbc8 100644
--- a/doc/emacs/package.texi
+++ b/doc/emacs/package.texi
@@ -35,8 +35,10 @@ Packages
 name of a package, and displays a help buffer describing the
 attributes of the package and the features that it implements.
 
-  By default, Emacs downloads packages from a package archive
-maintained by the Emacs developers and hosted by the GNU project.
+  By default, Emacs downloads packages from GNU ELPA
+(@url{https://elpa.gnu.org/}), a package archive maintained by the
+Emacs developers and hosted by the GNU project.  It also downloads
+packages from NonGNU ELPA (@url{https://elpa.nongnu.org/}).
 Optionally, you can also download packages from archives maintained by
 third parties.  @xref{Package Installation}.
 
-- 
2.35.1

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Eli Zaretskii]

> Cc: Stefan Monnier <monnier@iro.umontreal.ca>
> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sat, 26 Nov 2022 05:44:17 -0800
> 
> --- a/doc/emacs/package.texi
> +++ b/doc/emacs/package.texi
> @@ -35,8 +35,10 @@ Packages
>  name of a package, and displays a help buffer describing the
>  attributes of the package and the features that it implements.
>  
> -  By default, Emacs downloads packages from a package archive
> -maintained by the Emacs developers and hosted by the GNU project.
> +  By default, Emacs downloads packages from GNU ELPA
> +(@url{https://elpa.gnu.org/}), a package archive maintained by the
> +Emacs developers and hosted by the GNU project.  It also downloads
> +packages from NonGNU ELPA (@url{https://elpa.nongnu.org/}).

This sounds OK, but begs the question: what's short description of NonGNU
ELPA?  Since we describe GNU ELPA, let's also describe the other one.  The
purpose should IMO be to explain to the reader, or at least hint why we
maintain two separate archives.

Thanks.

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> This sounds OK, but begs the question: what's short description of NonGNU
> ELPA?  Since we describe GNU ELPA, let's also describe the other one.  The
> purpose should IMO be to explain to the reader, or at least hint why we
> maintain two separate archives.

What do you think of the below?

diff --git a/doc/emacs/package.texi b/doc/emacs/package.texi
index cdfb45d2042..3ac7dc83a60 100644
--- a/doc/emacs/package.texi
+++ b/doc/emacs/package.texi
@@ -38,9 +38,17 @@ Packages
   By default, Emacs downloads packages from GNU ELPA
 (@url{https://elpa.gnu.org/}), a package archive maintained by the
 Emacs developers and hosted by the GNU project.  It also downloads
-packages from NonGNU ELPA (@url{https://elpa.nongnu.org/}).
-Optionally, you can also download packages from archives maintained by
-third parties.  @xref{Package Installation}.
+packages from NonGNU ELPA
+(@url{https://elpa.nongnu.org/}).@footnote{GNU ELPA contains GNU
+packages that are available for use with Emacs, but are distributed
+separately from Emacs itself, for reasons of space.  NonGNU ELPA
+contains a selection of third-party packages that can not be included
+in GNU ELPA because their copyright has not yet been assigned to the
+Free Software Foundation.  For more information, see
+@uref{https://www.gnu.org/licenses/why-assign.html, Why the FSF Gets
+Copyright Assignments from Contributors}.}  Optionally, you can also
+download packages from archives maintained by third parties.
+@xref{Package Installation}.

   For information about turning an Emacs Lisp program into an
 installable package, @xref{Packaging,,,elisp, The Emacs Lisp Reference

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 8 Sep 2023 04:25:54 -0700
> Cc: 59609@debbugs.gnu.org, monnier@iro.umontreal.ca
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This sounds OK, but begs the question: what's short description of NonGNU
> > ELPA?  Since we describe GNU ELPA, let's also describe the other one.  The
> > purpose should IMO be to explain to the reader, or at least hint why we
> > maintain two separate archives.
> 
> What do you think of the below?

It's a good starting point, but the copyright assignment issue is not
the only issue (not even the main one, from my POV).  The main issue
with NonGNU ELPA, IMO, is that packages there don't necessarily adhere
to the Emacs coding conventions, are not supervised by the Emacs
maintainers, and do not have to coordinate their development decisions
with the Emacs team.  So their integration into Emacs could be less
seamless than that of packages from GNU ELPA.

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> It's a good starting point, but the copyright assignment issue is not
> the only issue (not even the main one, from my POV).  The main issue
> with NonGNU ELPA, IMO, is that packages there don't necessarily adhere
> to the Emacs coding conventions, are not supervised by the Emacs
> maintainers, and do not have to coordinate their development decisions
> with the Emacs team.  So their integration into Emacs could be less
> seamless than that of packages from GNU ELPA.

Thanks, based on that I ended up with this:

modified   doc/emacs/package.texi
@@ -35,10 +35,20 @@ Packages
 name of a package, and displays a help buffer describing the
 attributes of the package and the features that it implements.

-  By default, Emacs downloads packages from a package archive
-maintained by the Emacs developers and hosted by the GNU project.
-Optionally, you can also download packages from archives maintained by
-third parties.  @xref{Package Installation}.
+  By default, Emacs downloads packages from GNU ELPA
+(@url{https://elpa.gnu.org/}) and NonGNU ELPA
+(@url{https://elpa.nongnu.org/}), two package archives maintained by
+the Emacs developers and hosted by the GNU project.  @dfn{GNU ELPA}
+contains packages that are available for use with Emacs, but are
+distributed separately from Emacs itself.  @dfn{NonGNU ELPA} contains
+a selection of third-party packages that are not supervised by the
+Emacs maintainers, do not necessarily adhere to the Emacs coding
+conventions, and do not coordinate their development decisions with
+the Emacs team.  They have been selected to be useful to many people,
+but their integration into Emacs could be less seamless than that of
+packages from GNU ELPA.  Optionally, you can also download packages
+from archives maintained by third parties.  @xref{Package
+Installation}.

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Richard Stallman]

[[[ 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. ]]]

To make this cleader:

  > +the Emacs developers and hosted by the GNU project.  @dfn{GNU ELPA}
  > +contains packages that are available for use with Emacs, but are
  > +distributed separately from Emacs itself.

Let's use

  > +the Emacs developers and hosted by the GNU project.  @dfn{GNU ELPA}
  > +contains packages that we consider part of GNU Emacs, but that we
  > +distribute separately from the core Emacs.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>   > +the Emacs developers and hosted by the GNU project.  @dfn{GNU ELPA}
>   > +contains packages that are available for use with Emacs, but are
>   > +distributed separately from Emacs itself.
>
> Let's use
>
>   > +the Emacs developers and hosted by the GNU project.  @dfn{GNU ELPA}
>   > +contains packages that we consider part of GNU Emacs, but that we
>   > +distribute separately from the core Emacs.

I like that, thanks.


        Stefan

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Drew Adams]

> It's a good starting point, but the copyright assignment issue is not
> the only issue (not even the main one, from my POV).  The main issue
> with NonGNU ELPA, IMO, is that packages there don't necessarily adhere
> to the Emacs coding conventions, are not supervised by the Emacs
> maintainers, and do not have to coordinate their development decisions
> with the Emacs team.  So their integration into Emacs could be less
> seamless than that of packages from GNU ELPA.

+1.

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> It's a good starting point, but the copyright assignment issue is not
> the only issue (not even the main one, from my POV).  The main issue
> with NonGNU ELPA, IMO, is that packages there don't necessarily adhere
> to the Emacs coding conventions, are not supervised by the Emacs
> maintainers, and do not have to coordinate their development decisions
> with the Emacs team.  So their integration into Emacs could be less
> seamless than that of packages from GNU ELPA.

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.

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).


        Stefan

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  59609@debbugs.gnu.org
> Date: Fri, 08 Sep 2023 12:43:15 -0400
> 
> > It's a good starting point, but the copyright assignment issue is not
> > the only issue (not even the main one, from my POV).  The main issue
> > with NonGNU ELPA, IMO, is that packages there don't necessarily adhere
> > to the Emacs coding conventions, are not supervised by the Emacs
> > maintainers, and do not have to coordinate their development decisions
> > with the Emacs team.  So their integration into Emacs could be less
> > seamless than that of packages from GNU ELPA.
> 
> 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.

> 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.  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.

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.  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.

FTR, I feel responsible for GNU ELPA packages in the sense that I would
debug them if necessary. For Non-GNU ELPA packages I won't (exceptions
possible).

Furthermore, we offer debbugs bug tracking for GNU ELPA packages. I
don't know whether we offer the same fon Non-GNU ELPA packages.

Best regards, Michael.

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> 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

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Richard Stallman]

[[[ 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. ]]]

  > > 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.

Does "have" here stand for "exercise"?  I think so.

With GNU ELPA packages, in principle we can make the changes we wish.
However, for several reasons, we normally let the package developers
alone, except when there is an important reason to do otherwise, which
is rare.  When it makes sense for them to work independently, it is
better that they do.

It's the same for packages in core Emacs, those that have specific
developers.  We likewise let them do their work on their own as much
as possible.

However, it's different for NonGNU ELPA packages.  We would not want
to do more on them than fix small instances of bit-rot or simple
failures to fit into Emacs, even if the package becomes unmaintained.
Beyond that is not our responsibility.

If in practice we get involved in most of the packages that are part
of Emacs so rarely that it doesn't look very different from NonGNU
ELPA, that means we are doing well -- but that doesn't change the fact
that those categories are different in principle.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Richard Stallman]

[[[ 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. ]]]

  > +  By default, Emacs downloads packages from GNU ELPA
  > +(@url{https://elpa.gnu.org/}), a package archive maintained by the
  > +Emacs developers and hosted by the GNU project.  It also downloads
  > +packages from NonGNU ELPA (@url{https://elpa.nongnu.org/}).

I think it is ok to say this provided that these are packages we can't
or should not include in Emacs, so people can't depend on them
to continue to be present.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Richard Stallman]

[[[ 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'm correcting a message I didn't write clearly.

  > +  By default, Emacs downloads packages from GNU ELPA
  > +(@url{https://elpa.gnu.org/}), a package archive maintained by the
  > +Emacs developers and hosted by the GNU project.  It also downloads
  > +packages from NonGNU ELPA (@url{https://elpa.nongnu.org/}).

I said:

    I think it is ok to say this provided that these are packages we can't
    or should not include in Emacs, so people can't depend on them
    to continue to be present.

I should have said:

    I think it is ok to say this about NonGNU ELPA provided we say
    clearly that these are packages we can't or should not include in
    Emacs, so people should not depend on them to continue to be
    present.

Sorry.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

>   > +  By default, Emacs downloads packages from GNU ELPA
>   > +(@url{https://elpa.gnu.org/}), a package archive maintained by the
>   > +Emacs developers and hosted by the GNU project.  It also downloads
>   > +packages from NonGNU ELPA (@url{https://elpa.nongnu.org/}).
>
>     I think it is ok to say this about NonGNU ELPA provided we say
>     clearly that these are packages we can't or should not include in
>     Emacs, so people should not depend on them to continue to be
>     present.

I see no risk that the packages will suddenly go away.  Under what
circumstances would that happen?

In some cases, we will delete packages from NonGNU ELPA, of course.
This is true for GNU ELPA also, and for Emacs itself.  But I don't see
why we need to get into all that in this section, where we are just
letting people know that GNU ELPA and NonGNU ELPA exist.

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Richard Stallman]

[[[ 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 see no risk that the packages will suddenly go away.  Under what
  > circumstances would that happen?

Here are two ways I can envision.

If somehow the developers are no longer working on it in a way
we can use.

If it rots and needs substantial change and the developers
are not interested in doing that.

  >   But I don't see
  > why we need to get into all that in this section, where we are just
  > letting people know that GNU ELPA and NonGNU ELPA exist.

It's about two lines -- not enough to qualify as "all that".

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

>   > I see no risk that the packages will suddenly go away.  Under what
>   > circumstances would that happen?
>
> Here are two ways I can envision.
>
> If somehow the developers are no longer working on it in a way
> we can use.
>
> If it rots and needs substantial change and the developers
> are not interested in doing that.

I'm positive that these things can and will happen, but that's true also
for GNU ELPA and parts of Emacs itself (see lisp/obsolete/*.el).  Or
indeed with any software.  I'm not sure why this would need pointing out
specifically in the case of NonGNU ELPA.

Software dies at times.  C'est la vie.

>   >   But I don't see
>   > why we need to get into all that in this section, where we are just
>   > letting people know that GNU ELPA and NonGNU ELPA exist.
>
> It's about two lines -- not enough to qualify as "all that".

I was thinking more about the concept than the amount of text.  It
suggests that this concern is somehow specific to NonGNU ELPA.

FWIW, I believe the number of packages I've been using that have stopped
"being present" in my two decades or so with Emacs are... well, zero.
Zero packages.  Some are indeed unmaintained, but I still use them and
they work as well (or indeed badly) as they did ten or twenty years ago.

bug#59609: 29.0.50; [PATCH] Better advertise (Non-)GNU ELPA in emacs manual

[Richard Stallman]

[[[ 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 was asked this very specific question as part of a discussion
of the difference between NonGNU ELPA and GNU ELPA:

  > >   > I see no risk that the packages will suddenly go away.  Under what
  > >   > circumstances would that happen?
  > >

Here is how I responded to that one question:

  > > Here are two ways I can envision.
  > >
  > > If somehow the developers are no longer working on it in a way
  > > we can use.
  > >
  > > If it rots and needs substantial change and the developers
  > > are not interested in doing that.

You replied to that response, taking that question out of context:

  > I'm positive that these things can and will happen, but that's true also
  > for GNU ELPA and parts of Emacs itself (see lisp/obsolete/*.el).

That is true, but because it out of context, it appears to have implications
which it does not have.

When packages in the Emacs core go unmaintained, but they are still useful,
we roll up our sleeves and maintain them.  And we will try to do that
for GNU ELPA too, because they too are part of Emacs.

The point is that NonGNU ELPA packages have lower priority, so if they
become unmaintained, we might rather delete them than fix them.

Obsolete packages are a different thing.  We mark a package obsolete
when we think it is _better_ not to maintain it much.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)