* Re: completion-ui and other packages in GNU ELPA [not found] <20110527160050.GA23302@c3po> @ 2011-05-27 23:14 ` Stefan Monnier 2011-05-28 17:58 ` Ted Zlatanov 0 siblings, 1 reply; 3+ messages in thread From: Stefan Monnier @ 2011-05-27 23:14 UTC (permalink / raw) To: Toby Cubitt; +Cc: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: completion-ui and other packages in GNU ELPA 2011-05-27 23:14 ` completion-ui and other packages in GNU ELPA Stefan Monnier @ 2011-05-28 17:58 ` Ted Zlatanov 2011-05-29 2:22 ` Chong Yidong 0 siblings, 1 reply; 3+ messages in thread From: Ted Zlatanov @ 2011-05-28 17:58 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: completion-ui and other packages in GNU ELPA 2011-05-28 17:58 ` Ted Zlatanov @ 2011-05-29 2:22 ` Chong Yidong 0 siblings, 0 replies; 3+ messages in thread From: Chong Yidong @ 2011-05-29 2:22 UTC (permalink / raw) To: Ted Zlatanov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-05-29 2:22 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20110527160050.GA23302@c3po> 2011-05-27 23:14 ` completion-ui and other packages in GNU ELPA Stefan Monnier 2011-05-28 17:58 ` Ted Zlatanov 2011-05-29 2:22 ` Chong Yidong
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.