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