1 |
Hello, |
2 |
|
3 |
There are some packages which were 'readded' to the Sunrise overlay |
4 |
after lying unmaintained in the tree for a long time and finally being |
5 |
removed. One example could be net-im/ekg2 for removal of which I've been |
6 |
personally waiting. |
7 |
|
8 |
Although such a workflow 'works' indeed, for most of the users packages |
9 |
are just removed. Even if they use Sunrise, the delay of few days |
10 |
required in order to get the new ebuild rewritten and reviewed causes |
11 |
them to remove and forget about the package. And in fact, gx86 states |
12 |
it was 'removed'. |
13 |
|
14 |
Currently, the Sunrise policy states that there could be added only |
15 |
packages which are maintainer-wanted and thus not in gx86. For |
16 |
maintainer-needed, there is a proxy-commit mechanism but it's a little |
17 |
awkward, especially if the new ebuild is supposed to be written from |
18 |
scratch (like ekg2 one was). |
19 |
|
20 |
Wouldn't it be better to officially support moving unmaintained |
21 |
packages directly into Sunrise? In this case by 'unmaintained' I mean |
22 |
those which have open bugs assigned to 'maintainer-needed' for a long |
23 |
time, and are potentially a candidates for the treecleaning (not |
24 |
necessarily being in the removal queue yet). |
25 |
|
26 |
The particular Sunrise user wanting to maintain the package suggests |
27 |
moving it to Sunrise (to whom?). If developers agree on that, he is |
28 |
allowed to prepare the Sunrise ebuild and even commit it to the |
29 |
'sunrise' (non-public) tree. |
30 |
|
31 |
When Sunrise dev does the final review, after which the package would |
32 |
be moved to 'reviewed' (public) tree, he/she also masks the original |
33 |
package in gx86 stating that the package is now maintained in Sunrise. |
34 |
After 30 (or more) days, the masked gx86 packages are removed as usual. |
35 |
|
36 |
The advantage of such a workflow is quite obvious -- instead of seeing |
37 |
'removed' packages which they need to either copy to their own overlay |
38 |
or abandon, users are advised to add 'sunrise' to their repository list |
39 |
and use the user-maintained ebuild. And then the move is almost |
40 |
transparent to current Sunrise users. |
41 |
|
42 |
-- |
43 |
Best regards, |
44 |
Michał Górny |
45 |
|
46 |
<http://mgorny.alt.pl> |
47 |
<xmpp:mgorny@××××××.ru> |