On Wed, 2006-06-14 at 08:38 +0200, Kevin F. Quinn wrote:
> On Tue, 13 Jun 2006 23:19:51 +0100
> Stuart Herbert <[EMAIL PROTECTED]> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Michael Cummings wrote:
> > | Chris Gianelloni wrote:
> > |>> Using your example, if it will *never* make it into the tree,
> > then what |>> is it doing on *.gentoo.org infrastructure?
> > |
> > | OK, I'll speak up. I plan on using overlay.gentoo.org for the perl
> > team | overlay repository.
> > 
> > [snip]
> > 
> > You're not alone.
> > 
> > The webapps overlay contains ebuilds that may never make it into the
> > tree. We have a lot of packages that we maintain, but which don't
> > pass our upstream requirements [1] at this time.  We're doing our
> > best to work with $upstream on resolving such issues, but we're never
> > going to achieve a 100% success rate.
> 
> No-one is objecting to these project-local overlays.  The objection is
> to a system-wide overlay.

Correct.

I would have *no problem* with an opt-in system.  Instead of using
"InOverlay" (which is a poor choice anyway... which overlay?) as some
sort of tag, instead, assign the package to the project which maintains
the herd the package belongs to.  If the project does not want it, then
they can add "SUNRISE" to Keywords (in bugzilla).  The Sunrise project
then has permission to do with the package as they see fit.  At *this*
point, you could use "InOverlay", since it would be pretty obvious which
overlay it means.

The real root of the problem is that packages that were once assigned to
teams/projects are now being assigned into a generic dumping ground and
being forgotten.  You're trying to resolve this problem by moving them
to another dumping ground, which I completely disagree with.  A better
solution would be to revert the broken behavior, and start assigning
packages back to the projects, as it used to be done.  Let the project
decide if they want the package or not.  If they don't, then they can
simply add a single keyword and Sunrise can have at it.

This pleases everyone, as packages can be maintained in Sunrise, and the
projects still get to decide about packages that would likely affect
them.  It changes the project to an opt-in project, rather than having
to track down things and opt-out.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to