Chris Gianelloni <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 14 Jun 2006 09:34:16 -0400:
> Abusing loopholes in the rules doesn't make something "right". Agreed. However, it then points out the need for a rules change. >> Meanwhile, the Project Sunrise overlay /is/ a project specific overlay, >> and /is/ maintained by the project in question (Sunrise). That has been >> specifically stated in the Project Sunrise formulation. > > Correct. However, it is attempting to work with ebuilds/packages that > are owned by other projects currently. *This* is my objection. But if they aren't in the tree, they aren't part of a herd, and therefore can't really be owned by a project, particularly if that project has had a chance to put it in the tree and hasn't taken it (whether due to lack of manpower or whatever). Now, there's a difference between an active rejection -- this is not fit for the tree nor can it be and here's why -- and a simple lack of manpower rejection, which is why giving the project that might normally take it over if it were to be in the tree dibs on accepting/rejecting it is good, but a default to being available for sunrise to sponsor if the project doesn't respond either way within a reasonable time (which would indicate a lack of manpower or interest in doing so, thus leaving it available should others choose to do so) seems reasonable within context. Not that I have any immediate plans to use it at this time, but I could conceivably use it for one or more single packages -- tho I expect I'll be examining each individual ebuild as I merge and upgrade it if I do -- the security issues are real to me too, and I'm not quite /that/ insane. =8^) -- 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 -- gentoo-dev@gentoo.org mailing list
