Henrik Brix Andersen wrote:
On Wed, Jun 14, 2006 at 09:18:57AM -0400, Chris Gianelloni wrote:
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.
Except there is a flaw in your idea. As I see it, nothing prevents the
developers of Project Sunrise from joining each and every team
currently in existance and start marking enhancement requests
"SUNRISE", regardless of the general opinion of the team/project.
I would presume if the team is against that the hypothetical developer
would find him(her)self in a sticky situation and perhaps even get
kicked off of the team(s) in question. Some teams actually talk to each
other, have policy, etc.
I am not in favor of an opt-in/opt-out system.
Regards,
Brix
--
gentoo-dev@gentoo.org mailing list
