Re: GNU ELPA package discoverability

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

  > This sounds like an interesting proposal.  A similar system is used for the
  > package management system of the Arch Linux GNU/Linux distribution:

  > - core repository: Essential packages for setting up a base system.
  > - community repository: Packages the community considers essential, adopted
  >   by a "Trusted User" (TU) to ensure quality standards and ongoing
  >   maintenance.
  > - Arch User Repository (AUR): External repository allowing anyone to submit
  >   packages in source form, these can be installed using an AUR helper
  >   program (which themselves are part of the AUR).

If this is simply a matter of three different levels of maintenance, I
see no reason we can't have all three for ELPA packages.  But it is
rather complicated, and managing that will take work.  Having just two
levels may be enough, and it is much simpler.

Arch GNU/Linux does not face the issue of making sure that packages
don't recommend nonfree software.  Indeed, it includes nonfree
programs.  But that issue is part of our core goal.
We cannot follow their example into working against our principles.

>From that rough description of the Arch User Repository, I get the
impression it doesn't have any step at which that checking would be
done.  So we would have to add that.

  > - Users familiar with commit access to that "second ELPA" identify important
  >   community packages and contact their maintainers.
  > - Packages are reviewed for their overall quality (license, release policy,
  >   code style, ...).
  > - Package releases are tested and included in that "second ELPA".
  > - Packages of exceptional quality may be promoted to GNU ELPA.

GNU ELPA will require copyright assignment.  It will be only for
packages that, aside from practicalities, are like core Emacs.

  > - The naming is important. GNU ELPA is a bit unfortunate as a name, it
  >   consists of a license identifier and a technology.

GNU is an operating system, and the project to develop it.  I wrote
licenses for it, so we call them "GNU licenses", but those licenses
are not the meaning of the name "GNU".

GNU ELPA is the ELPA that the GNU Project supports.

Nonetheless, I take your point.

    > Perhaps it's late, but a rename to ensure consistency with the "second
    > ELPA" would help with adoption of the proposal.

It is somewhat late, but not impossible if we find a clearly better name.

  > - The exact relationship between GNU ELPA, the "second ELPA" and
  >   community-provided ELPA repositories needs to be clarified and clearly
  >   documented in the manuals to help users choose the appropriate
  >   repositories to install packages from.

If "community-provided ELPA repositories" means those that include
packages that depend on nonfree programs, we can't "work with" that.
The only thing we can legitimately say about them is "don't go there."

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