1 |
Am 13.06.2010 22:36, schrieb Duncan: |
2 |
> Jorge Manuel B. S. Vicetto posted on Sun, 13 Jun 2010 14:26:26 +0000 as |
3 |
> excerpted: |
4 |
> |
5 |
>> there was a proposal to create a sunset overlay, like the java team used |
6 |
>> and now kde uses as well. The purpose of this overlay would be to keep |
7 |
>> the packages that are removed from the tree because they have no |
8 |
>> maintainers. As was discussed back then, the people wishing to work on |
9 |
>> sunrise are likely not interested in having all the removed packages |
10 |
>> dumped in their shoulders. Besides, sunrise is about packages that have |
11 |
>> an interested user submitting and hopefully maintaining ebuilds for new |
12 |
>> packages, while sunset is likely to become a dumping ground for stuff |
13 |
>> that we can't find anyone to take care of. If we want to find a way to |
14 |
>> not drop the maintainer-needed packages, I'd prefer we move them to |
15 |
>> sunset and not to sunrise. As this overlay is likely to become large, |
16 |
>> probably "huge", and as it will host security vulnerable packages, we |
17 |
>> should evaluate whether we really want to host it and, if so, what |
18 |
>> measures to take to protect "distracted users". I think package masking |
19 |
>> all the packages put there with links to relevant bugs might be a first |
20 |
>> step. |
21 |
> |
22 |
> You obviously read the proposal differently than I did. MG can pop in and |
23 |
> say what he intended, but as I read it, and why I said "++", is... |
24 |
> |
25 |
> We change the policy of sunrise, not to be a dumping ground for /all/ tree- |
26 |
> cleaned packages, but to allow interested users who see that a package |
27 |
> they're interested in is unmaintained, to add it to (the unpublic part of) |
28 |
> sunrise before the package is removed and potentially before it's even |
29 |
> masked for removal, such that it can be approved and ready to "go public" |
30 |
> in sunrise at the same time it's removed (or even when masked for removal) |
31 |
> from the main tree. |
32 |
> |
33 |
> So packages wouldn't be dumped there without a maintainer. The only ones |
34 |
> that would qualify would be those where a user actively proposes to |
35 |
> maintain them in sunrise, the idea being that in some instances (as with |
36 |
> the posted example), they can be maintained better there than they can be |
37 |
> proxy-maintained in-tree. |
38 |
> |
39 |
> Apparently, sunrise has been around long enough, now, that there has been |
40 |
> at least one package that started in sunrise, was added to the tree, then |
41 |
> the person who added it lost interest or retired... and now it's rotting |
42 |
> in the tree, and the same user that put it in sunrise before is still |
43 |
> interested in it and has updated ebuilds, etc, but can't easily get |
44 |
> proxies to commit the new ebuilds to the tree. From my read, that was |
45 |
> apparently what sparked the post and whole proposed change. |
46 |
> |
47 |
|
48 |
I think, your proposed way is already possible. The policy of sunrise is only to not dublicate |
49 |
packages in main tree. If they will surely be dropped and this fact can be seen in public, e.g. |
50 |
because of the announcement and mask, i have no problems with users joining #gentoo-sunrise and |
51 |
maintaining that package in sunrise overlay. |
52 |
|
53 |
You should just remember, that those, who want to add the unmaintained package to sunrise, should |
54 |
also plan to maintain it there, sunrise will not become a place to move broken packages to ;-) |
55 |
|
56 |
-- |
57 |
Thomas Sachau |
58 |
|
59 |
Gentoo Linux Developer |