[gentoo-dev] Moving unmaintained packages to Sunrise
Hello, There are some packages which were 'readded' to the Sunrise overlay after lying unmaintained in the tree for a long time and finally being removed. One example could be net-im/ekg2 for removal of which I've been personally waiting. Although such a workflow 'works' indeed, for most of the users packages are just removed. Even if they use Sunrise, the delay of few days required in order to get the new ebuild rewritten and reviewed causes them to remove and forget about the package. And in fact, gx86 states it was 'removed'. Currently, the Sunrise policy states that there could be added only packages which are maintainer-wanted and thus not in gx86. For maintainer-needed, there is a proxy-commit mechanism but it's a little awkward, especially if the new ebuild is supposed to be written from scratch (like ekg2 one was). Wouldn't it be better to officially support moving unmaintained packages directly into Sunrise? In this case by 'unmaintained' I mean those which have open bugs assigned to 'maintainer-needed' for a long time, and are potentially a candidates for the treecleaning (not necessarily being in the removal queue yet). The particular Sunrise user wanting to maintain the package suggests moving it to Sunrise (to whom?). If developers agree on that, he is allowed to prepare the Sunrise ebuild and even commit it to the 'sunrise' (non-public) tree. When Sunrise dev does the final review, after which the package would be moved to 'reviewed' (public) tree, he/she also masks the original package in gx86 stating that the package is now maintained in Sunrise. After 30 (or more) days, the masked gx86 packages are removed as usual. The advantage of such a workflow is quite obvious -- instead of seeing 'removed' packages which they need to either copy to their own overlay or abandon, users are advised to add 'sunrise' to their repository list and use the user-maintained ebuild. And then the move is almost transparent to current Sunrise users. -- Best regards, Michał Górny http://mgorny.alt.pl xmpp:mgo...@jabber.ru signature.asc Description: PGP signature
Re: [gentoo-dev] Moving unmaintained packages to Sunrise
On 06/13/2010 10:41 AM, Michał Górny wrote: Wouldn't it be better to officially support moving unmaintained packages directly into Sunrise? In this case by 'unmaintained' I mean those which have open bugs assigned to 'maintainer-needed' for a long time, and are potentially a candidates for the treecleaning (not necessarily being in the removal queue yet). What's stopping you or any of the sunrise guys to pick up packages when treecleaners send the last rites? You have 30 days minimum, to get a new ebuild rolling before it gets the axe. Sounds like plenty of time to me. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving unmaintained packages to Sunrise
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13-06-2010 08:41, Michał Górny wrote: Hello, There are some packages which were 'readded' to the Sunrise overlay after lying unmaintained in the tree for a long time and finally being removed. One example could be net-im/ekg2 for removal of which I've been personally waiting. Although such a workflow 'works' indeed, for most of the users packages are just removed. Even if they use Sunrise, the delay of few days required in order to get the new ebuild rewritten and reviewed causes them to remove and forget about the package. And in fact, gx86 states it was 'removed'. Currently, the Sunrise policy states that there could be added only packages which are maintainer-wanted and thus not in gx86. For maintainer-needed, there is a proxy-commit mechanism but it's a little awkward, especially if the new ebuild is supposed to be written from scratch (like ekg2 one was). Wouldn't it be better to officially support moving unmaintained packages directly into Sunrise? In this case by 'unmaintained' I mean those which have open bugs assigned to 'maintainer-needed' for a long time, and are potentially a candidates for the treecleaning (not necessarily being in the removal queue yet). I think you might not have been around at that time, but when the sunrise overlay was created, there was a proposal to create a sunset overlay, like the java team used and now kde uses as well. The purpose of this overlay would be to keep the packages that are removed from the tree because they have no maintainers. As was discussed back then, the people wishing to work on sunrise are likely not interested in having all the removed packages dumped in their shoulders. Besides, sunrise is about packages that have an interested user submitting and hopefully maintaining ebuilds for new packages, while sunset is likely to become a dumping ground for stuff that we can't find anyone to take care of. If we want to find a way to not drop the maintainer-needed packages, I'd prefer we move them to sunset and not to sunrise. As this overlay is likely to become large, probably huge, and as it will host security vulnerable packages, we should evaluate whether we really want to host it and, if so, what measures to take to protect distracted users. I think package masking all the packages put there with links to relevant bugs might be a first step. The particular Sunrise user wanting to maintain the package suggests moving it to Sunrise (to whom?). If developers agree on that, he is allowed to prepare the Sunrise ebuild and even commit it to the 'sunrise' (non-public) tree. When Sunrise dev does the final review, after which the package would be moved to 'reviewed' (public) tree, he/she also masks the original package in gx86 stating that the package is now maintained in Sunrise. After 30 (or more) days, the masked gx86 packages are removed as usual. The advantage of such a workflow is quite obvious -- instead of seeing 'removed' packages which they need to either copy to their own overlay or abandon, users are advised to add 'sunrise' to their repository list and use the user-maintained ebuild. And then the move is almost transparent to current Sunrise users. The problem with the above is exposing users to potentially dangerous applications - from a security perspective. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMFOqSAAoJEC8ZTXQF1qEPVh0QAKT38JEDUHY4neIhQ44m5aeL sqZIfIULeVY4Xh5EaGJ/kS1cLyFuy+QXU2y/NLFWT7+DD9vPZiUGx/z90ph6irVC YURd9scd4SdDKJKv2vp56A0USPXfRqRxok6l1m2HvZaqMoV+WN9Y+WQ/wxcu69Ce 2hDUikABMwAazjA5GotfC7Wa5Aadk6+6fYVSMiCZAtpD35rq+9yLJ8wJFr0YQq50 1Cj/B2vyA90uXRG/wfWhetU+sOLsOoF0yGoINHMzRon6J8SgQr+5mLsQYL1JhcsK yNem0omoBB0qio4kihxT5L11n8rK2nesLr+ay93udfPc/0hHy6J6rK+ZCW5alG1r fARHgKcdU+HPwXKp2xhAJyo/ooHZFN32DhEfEE6RF5M2KS4wq2kNhLnh0mnMRjtV GhH3TWC8DFuMwZDFwYZs99G1biCmc4jaw7xyAx9Q3c60vB0UGeVPlCb73CwuE3we 5YHuEyG2TY7Xju7wGm/KLte70FUK+MynJL+yaF4fkxkVz7YzOSTMcEv9YgvWJ3kF aa1U1B6TQxEqqR2w734SNB3dE/BMyrWXvJ8WMfw63NpDRfkEVmC9ogarLvOtEjQ0 GQ9Id7hx85B+1+8LsKwrHJu09cEDsB7k0+l2AFGJ8llWX8ptBeYhZfLzhPzYllhB DEUzrXPW7/AyrLwpyU8j =7Q9z -END PGP SIGNATURE-
Re: [gentoo-dev] Moving unmaintained packages to Sunrise
On 06/13/2010 05:26 PM, Jorge Manuel B. S. Vicetto wrote: Wouldn't it be better to officially support moving unmaintained packages directly into Sunrise? In this case by 'unmaintained' I mean those which have open bugs assigned to 'maintainer-needed' for a long time, and are potentially a candidates for the treecleaning (not necessarily being in the removal queue yet). I think you might not have been around at that time, but when the sunrise overlay was created, there was a proposal to create a sunset overlay, like the java team used and now kde uses as well. We (java) still use it and call it junkyard. That's an adequate description for the quality of the overlay. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving unmaintained packages to Sunrise
On 06/13/10 16:26, Jorge Manuel B. S. Vicetto wrote: If we want to find a way to not drop the maintainer-needed packages, I'd prefer we move them to sunset and not to sunrise. Agreed. If there is a user-maintainer move to sunrise, if there isn't move to sunset. As this overlay is likely to become large, probably huge, and as it will host security vulnerable packages, we should evaluate whether we really want to host it and, if so, what measures to take to protect distracted users. I think package masking all the packages put there with links to relevant bugs might be a first step. We introduced a graveyard quality level to layman recently that allows for marking such repositories (and a split tree in the future). Quoting the current repositories.dtd: [..] quality (core|stable|testing|experimental|graveyard) #REQUIRED [..] So Layman can be made handling such a repo specially, say displaying certain warnings. Sebastian
