Re: ELPA update

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

> I second that.  Currently, I don't use GNU's ELPA but have a checkout of
> the emacs elpa branch that I update and "make site" daily, and then I
> add the "elpa/packages/<foo>/" dirs of the packages I'm interested into
> my load-path manually.  That completely defeats the purpose of a package
> manager...

FWIW I use "make site" and then add the following to my .emacs:

   (eval-after-load 'package
     '(add-to-list 'package-directory-list "~/src/emacs/elpa/site"))
   (setq package-load-list '((auctex nil) all))
   (if (fboundp 'package-initialize) (package-initialize))

Whether it defeats the purpose of a package manager, I cannot tell, but
it does let me use the GNU ELPA packages transparently without having to
install them one by one and upgrade them, etc... and it forces me to
test the harmlessness of those packages.

BTW here's a few things about GNU ELPA, some of which are calls for help:
- We need someone to write some script that can split a stream of "elpa
  commit email messages" and dispatch them to the respective
  package maintainers.
  I consider this very important and urgent and would really welcome
  help on this.
- We need to improve the "make site" so that the compile warnings aren't
  drowned with everything else.
- We need to improve the "make archive" so it includes a ChangeLog in
  each package.
- I'd like to push GNU ELPA as a kind of "Savannah for Elisp".
  That means I encourage package maintainers to use elpa's Bzr as their
  official VCS repository.  This currently means that any package
  maintainer needs to be a member of the `emacs' group and gets write
  access not just to his package but also to other packages and to
  Emacs.  I'm not sure how well this is going to scale, but let's
  be optimistic.
- If the `elpa' repository is used for active development, that means it
  may contain packages in "unreleasable state", so we'll want to come up
  with some convention to indicate when a new release is made (and
  "make archive" should obey that).
- I'm a bit concerned about authorship (we keep a pretty close eye on
  it within Emacs, but I don't know/think we can do the same for all
  packages in GNU ELPA since not all patches will have gone through
  emacs-devel), so I'm thinking that the *VC-Log* should not
  just start with "Summary: \n\n" but with "Summary: \nAuthor: \n\n".


        Stefan