From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-dev+bounces-41246-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1ONtwZ-0006x8-8H
for garchives@archives.gentoo.org; Sun, 13 Jun 2010 20:38:11 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 6BA91E0D35;
Sun, 13 Jun 2010 20:38:01 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
by pigeon.gentoo.org (Postfix) with ESMTP id D7F45E0D29
for <gentoo-dev@lists.gentoo.org>; Sun, 13 Jun 2010 20:37:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp.gentoo.org (Postfix) with ESMTP id 759111B409D
for <gentoo-dev@lists.gentoo.org>; Sun, 13 Jun 2010 20:37:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at gentoo.org
X-Spam-Score: -1.8
X-Spam-Level:
X-Spam-Status: No, score=-1.8 required=5.5 tests=[AWL=-0.690, BAYES_05=-1.11]
Received: from smtp.gentoo.org ([127.0.0.1])
by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Z5i56waawIbb for <gentoo-dev@lists.gentoo.org>;
Sun, 13 Jun 2010 20:37:10 +0000 (UTC)
Received: from lo.gmane.org (lo.gmane.org [80.91.229.12])
by smtp.gentoo.org (Postfix) with ESMTP id C16681B40AD
for <gentoo-dev@gentoo.org>; Sun, 13 Jun 2010 20:37:08 +0000 (UTC)
Received: from list by lo.gmane.org with local (Exim 4.69)
(envelope-from <lnx-gentoo-dev@m.gmane.org>)
id 1ONtvQ-0004ql-50
for gentoo-dev@gentoo.org; Sun, 13 Jun 2010 22:37:00 +0200
Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-dev@gentoo.org>; Sun, 13 Jun 2010 22:37:00 +0200
Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-dev@gentoo.org>; Sun, 13 Jun 2010 22:37:00 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: gentoo-dev@lists.gentoo.org
connect(): No such file or directory
From: Duncan <1i5t5.duncan@cox.net>
Subject: [gentoo-dev] Re: Moving unmaintained packages to Sunrise
Date: Sun, 13 Jun 2010 20:36:47 +0000 (UTC)
Message-ID: <pan.2010.06.13.20.36.46@cox.net>
References: <20100613104143.4f61dbe7@pomiocik.lan>
<4C14EA92.4020008@gentoo.org>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net
User-Agent: Pan/0.133 (House of Butterflies; GIT a971f44 branch-testing)
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 5aec4d47-c5ff-4742-9390-95dcc16ad5e1
X-Archives-Hash: 579625e10d57fe4cafc9239cc1ad9db7
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 use=
d
> 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 an=
d=20
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/ tre=
e-
cleaned packages, but to allow interested users who see that a package=20
they're interested in is unmaintained, to add it to (the unpublic part of=
)=20
sunrise before the package is removed and potentially before it's even=20
masked for removal, such that it can be approved and ready to "go public"=
=20
in sunrise at the same time it's removed (or even when masked for removal=
)=20
from the main tree.
So packages wouldn't be dumped there without a maintainer. The only ones=
=20
that would qualify would be those where a user actively proposes to=20
maintain them in sunrise, the idea being that in some instances (as with=20
the posted example), they can be maintained better there than they can be=
=20
proxy-maintained in-tree.
Apparently, sunrise has been around long enough, now, that there has been=
=20
at least one package that started in sunrise, was added to the tree, then=
=20
the person who added it lost interest or retired... and now it's rotting=20
in the tree, and the same user that put it in sunrise before is still=20
interested in it and has updated ebuilds, etc, but can't easily get=20
proxies to commit the new ebuilds to the tree. From my read, that was=20
apparently what sparked the post and whole proposed change.
--=20
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