Re: completion-ui and other packages in GNU ELPA

Re: completion-ui and other packages in GNU ELPA

[Stefan Monnier]

>> How do you feel about installing some of your packages into the
>> GNU ELPA?  I think completion-ui is a good candidate but probably
>> several others as well (undo-tree, predictive).

> I'd be happy to. I see there's a new section in the Elisp manual on how
> to prepare packages for ELPA. Presumably I need to follow the
> instructions there, and send the resulting package to you (or someone
> else?) to install?

Sounds about right.

> How are package updates be handled? Same way? (I googled, but didn't
> find a clear description of the procedure, only archived mailing
> list discussions.)

That's a good question.  Currently packages are basically installed into
the `elpa' branch as is.  We could give you write access there so you
can install updates and even use it as your official repository.
But maybe we should come up with a plan so we can give separate branches
per-package rather than one big branch with all the packages in it, so
as to make it easier for package maintainers to manage their packages.

> If it's OK with you, it would probably be easier for me to package
> undo-tree first, to get the hang of things, as it's a single-file
> package. Once I've understood how it's supposed to work in the simpler
> case of undo-tree, I can move on to the multi-file completion-UI and
> predictive packages.

Fine by me.  Single-file packages are trivial to package.

As for your avl-tree.el changes, I've just installed them.  Thanks,


        Stefan

Re: completion-ui and other packages in GNU ELPA

[Ted Zlatanov]

On Fri, 27 May 2011 20:14:53 -0300 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> That's a good question.  Currently packages are basically installed into
SM> the `elpa' branch as is.  We could give you write access there so you
SM> can install updates and even use it as your official repository.
SM> But maybe we should come up with a plan so we can give separate branches
SM> per-package rather than one big branch with all the packages in it, so
SM> as to make it easier for package maintainers to manage their packages.

How about keeping track of package locations (a branch, Github,
wherever) and then downloading them nightly?  The publishing step, then,
would be manual and consist of reviewing what has changed since the last
commit (which is also the last publish), committing the new contents,
and finally deploying it all to the HTML tree.

I would not make it possible for package maintainers to directly affect
the HTML tree of the GNU ELPA.  But perhaps I'm too worried :)

Ted

Re: completion-ui and other packages in GNU ELPA

[Chong Yidong]

Ted Zlatanov <tzz@lifelogs.com> writes:

> How about keeping track of package locations (a branch, Github,
> wherever) and then downloading them nightly?  The publishing step, then,
> would be manual and consist of reviewing what has changed since the last
> commit (which is also the last publish), committing the new contents,
> and finally deploying it all to the HTML tree.
>
> I would not make it possible for package maintainers to directly affect
> the HTML tree of the GNU ELPA.  But perhaps I'm too worried :)

Too many moving parts.  I don't think this is enough of a concern to
justify such inconveniences.

The current setup, i.e. giving anyone with access to the Emacs dev
sources the same access to the elpa repository, and deploying manually
from the elpa repository to the server, already strikes the right
balance IMO.