Re: ELPA policy

[Stefan Monnier <monnier@iro.umontreal.ca>]

> This topic has been recently brought by Lars, Ted and me on the gnus
> mailing list. I've been asked to move this discussion here for
> clarification.

As mentioned Chong, it's still "work in progress" from this point
of view.  But since your questions use the future tense, I'll try to
reply based on what I think should happen in the future.

> - Who will be able to upload to ELPA?

Depends: new packages or updates to existing packages?
For new packages, I'd expect only a few people to have such rights, but
for updates, I'd expect something like "anybody with access to the Bzr
repository".  After all, if they can screw with the main Emacs codebase,
why not with the ELPA packages.

> - Who will fix the packages' bugs?

The upstream maintainers, I'd expect.  That's one of the reasons to have
packages outside of Emacs's tree.

> - Who will assure there's no regression for Emacs 24.1 user when people
>   will starts uploading packages using 24.2 only function?

The upstream maintainer, for the same reason.

> - Who will assure there's no regression at all?

In which sense?  I'd expect the upstream maintainer to take some role
here, but admittedly, since those packages are easily available in
a central place, it's more likely that Emacs maintainers will pay
attention to them when introducing changes to the core.

> - Who will assure there's no really bad things uploaded?

The same people who currently assure that there's no really bad things
installed in the Emacs trunk.

> - Will all new packages go to ELPA, or with some still go to Emacs
>   trunk? And if some can go to the trunk, upon which rules?

We don't have rules for it, right now.  Here are some considerations, on
top of what Chong mentioned:
- in order to keep Emacs maintainable, we'd rather have packages in
  ELPA, all things being equal.
- packages of general usefulness (e.g. libraries) are good candidates
  for inclusion in Emacs, to reduce dependencies among ELPA packages.
  
> - Will all/most of the current packages be moved to ELPA?

Definitely not (in the foreseeable future).

> There's probably a lot more question outstanding. I've the feeling ELPA
> is adding a second class citizenship for packages, and I really do not
> like that, at least in its current form.

We currently have two kinds of packages: bundled and unbundled.  So ELPA
is about adding a third kind in-between, with properties such as
"smooth integration", "ease of installation", ... to be halfway between
the other two.


        Stefan