Re: GNU ELPA package discoverability

[Vasilij Schneidermann <mail@vasilij.de>]

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

> I'm thinking about making a second ELPA which won't require copyright
> assignment.

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

There are several more repositories in this picture that I didn't mention
for simplicity's sake.  The idea is that new community packages are
submitted to the AUR; if they prove to be sufficiently popular, a user may
contact a TU for inclusion into the community repository.  If the package
doesn't prove to hold their ground, it can be removed from the community
repository and added back to the AUR again.  A TU typically maintains around
10-30 packages.

Here's how I imagine the model to be adapted for our purposes:

- 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.
- Problematic packages (lack of upstream communication, ...) may be demoted and
  become a regular community package again.

Some crucial points with this proposal:

- The naming is important. GNU ELPA is a bit unfortunate as a name, it
  consists of a license identifier and a technology.  It's not uncommon to
  contract it to just ELPA which causes confusion with the technology.
  Perhaps it's late, but a rename to ensure consistency with the "second
  ELPA" would help with adoption of the proposal.
- There must be some obvious benefit to the "second ELPA" for users.  The
  most obvious one is that there will be a vetted collection of packages
  installable out of the box.  Perhaps more can be added, such as a
  guarantee of their overall quality.  A common issue with
  community-provided ELPA repositories is the lack of quality assurance,
  for example upgrading all installed packages is a gamble, with breakage
  being a common side effect.  If that "second ELPA" avoids this issue,
  that would make for a strong case.
- 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.  For example users caring about
  maximal stability would be advised to stick to the official ELPA
  repositories, but users seeking to install any kind of packages should
  look into community repositories, with the appropriate disclaimers.

Vasilij

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]