-----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-----
