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>

Attachment: signature.asc
Description: PGP signature

Reply via email to