Improving GNU ELPA (was: Adding advisory notification for non-ELPA package.el downloads)

[Stefan Monnier]

> for inclusion.  Getting into ELPA requires subtle git invocations that end
> up mashing up the history of your project with that of tens of others, while
> fearing to break the entire ELPA repo because of a missing copyright line
> in a test file.
> And ELPA makes maintaining the package more painful, too: picking out the
> commits made by others and copying them on your personal repo requires
> further arcane git invocations — same for importing new commits from your
> personal repo. And of course you lose other MELPA goodies, like getting
> download statistics.

While most of the above only applies to the case where you put your
package as a "subtree" rather than an "external", I can't say that the
criticism is unfair.

And I indeed think that if we want to expand the use of ELPA, the
proverbial someone should first work on the elpa.gnu.org infrastructure.
It's all a simple matter of writing scripts, really, so help is very
welcome.

I know of the following:
- when someone commits to elpa.git we get an elpa-diffs email which
  I used to then forward to the corresponding package maintainer.
  This forwarding is currently broken because of changes to my
  email server.  This should really be done in elpa.gnu.org instead of
  iro.umontreal.ca anyway, so I don't intend to fix the old setup.

- elpa.gnu.org should be notified (e.g. via the elpa-diffs thingy)
  whenever a commit is made to an elpa package, and should then build
  the corresponding package (if the version was changed).  Currently, we
  just rebuild the world blindly twice a day, which is both more costly
  and adds a ~6h delay.  More importantly, this will make the handling
  of "externals" just as efficient as "subtrees", so it will scale
  a lot better.

- once that's in place, we could also consider supporting "one
  repository per package" rather than "one branch per package".

- we have the web-server log, so we could provide download stats.

Publishing on GNU ELPA is inevitably more work than on MELPA:
- you need to sign paperwork.
- we don't want to fetch from non-GNU servers, so we need the maintainer
  to push to elpa.git explicitly.
- we want the elpa.git code to be writable by "Emacs maintainers", so
  the package's maintainer will sometimes have to deal with commits made
  outside of his control.

But we could tilt the balance the other way.  The way I see GNU ELPA,
it doesn't just provide package distribution but also package hosting,
so we could maybe move towards a gitea/gogs/gitlab/younameit system
for it.  We could add some wiki or some way for users to vote up/down
and add comments to each package, ...

IOW, elpa.gnu.org needs some tender love from someone who understands
the web.  So far I've been doing most of the maintenance and I don't
understand the web, really.


        Stefan