Created attachment 347368 [details] live ebuild Please commit attached live ebuild.
Created attachment 347370 [details] live ebuild default S is fine.
do we really need it in the main tree?
Upstream hg default branch is stable, live ebuild is useful for testing new features. Also now quiterss uses system sqlite without any patches.
+ 06 May 2013; Sergey Popov <pinkbyte@gentoo.org> +quiterss-9999.ebuild: + Add live ebuild, wrt bug #468602, thanks to Nikoli <nikoli AT lavabit.com>
(In reply to comment #2) > do we really need it in the main tree? No, of course not. We normally keep live ebuilds in the overlay.
(In reply to comment #5) > (In reply to comment #2) > > do we really need it in the main tree? > > No, of course not. We normally keep live ebuilds in the overlay. I'm not against having it in portage, provided that it's mostly stable and Nikoli volunteers to proxy-maintain it.
It is my main feed reader now, upstream is responsive, so adding me to metadata.xml is fine.
+ 07 May 2013; Sergey Popov <pinkbyte@gentoo.org> metadata.xml: + Reformat metadata, add Nikoli <nikoli AT lavabit.com> as maintainer of live + ebuild done
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #2) > > > do we really need it in the main tree? > > > > No, of course not. We normally keep live ebuilds in the overlay. > > I'm not against having it in portage, provided that it's mostly stable and > Nikoli volunteers to proxy-maintain it. It is accepted policy (tho not a strict requirement) in Gentoo to not keep live ebuilds in the portage tree, but to prefer snapshots if necessary. Since we have an overlay that we use for practically all of our live ebuilds, I would strongly suggest we do the same here. But I'll leave it up to the actual maintainers to decide.
(In reply to comment #9) > It is accepted policy (tho not a strict requirement) in Gentoo to not keep > live ebuilds in the portage tree, but to prefer snapshots if necessary. > Since we have an overlay that we use for practically all of our live > ebuilds, I would strongly suggest we do the same here. But I'll leave it up > to the actual maintainers to decide. +1