[gentoo-dev] Re: Moving unmaintained packages to Sunrise

[Duncan]

Jorge Manuel B. S. Vicetto posted on Sun, 13 Jun 2010 14:26:26 +0000 as
excerpted:

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

You obviously read the proposal differently than I did.  MG can pop in and 
say what he intended, but as I read it, and why I said "++", is...

We change the policy of sunrise, not to be a dumping ground for /all/ tree-
cleaned packages, but to allow interested users who see that a package 
they're interested in is unmaintained, to add it to (the unpublic part of) 
sunrise before the package is removed and potentially before it's even 
masked for removal, such that it can be approved and ready to "go public" 
in sunrise at the same time it's removed (or even when masked for removal) 
from the main tree.

So packages wouldn't be dumped there without a maintainer.  The only ones 
that would qualify would be those where a user actively proposes to 
maintain them in sunrise, the idea being that in some instances (as with 
the posted example), they can be maintained better there than they can be 
proxy-maintained in-tree.

Apparently, sunrise has been around long enough, now, that there has been 
at least one package that started in sunrise, was added to the tree, then 
the person who added it lost interest or retired... and now it's rotting 
in the tree, and the same user that put it in sunrise before is still 
interested in it and has updated ebuilds, etc, but can't easily get 
proxies to commit the new ebuilds to the tree.  From my read, that was 
apparently what sparked the post and whole proposed change.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman