On Wed, 2006-06-14 at 08:52 +0000, Duncan wrote: > But as Stuart Herbert pointed out, a project can be self-authorized, by > the current rules. Project Sunrise therefore didn't /need/ permission to > come into existence and set up its own overlay. The announcement here, > while perhaps it /should/ have been discussed as a proposal first, > therefore didn't break the rules as they are now.
Abusing loopholes in the rules doesn't make something "right". > 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. > Furthermore, there's specific allowance for competing projects, and as > Stuart again points out, ebuilds form herds which are maintained by > projects, and once a project rejects the ebuild, it can then be picked up > by another developer or project, in which case the project that rejected > it is no more responsible for it except that they can continue to refuse > that it be in that project. The "competing projects" idea really is stupid. Unfortunately, there's nothing that I can do about that at this time except ask that the idea be either clarified or rejected by the council. Two projects "competing" to produce a similar product (like, say two projects trying to come up with a next-generation genkernel) is one thing. Two "competing" projects maintaining the same herd space within the portage tree is something else. This creates animosity between the projects, is completely against the ideas of fostering cooperation and teamwork, and generally sticks it to our users due to a few egos. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
