| 1 |
Chris Gianelloni <wolf31o2@g.o> posted |
| 2 |
1150234358.13805.51.camel@×××××××××××××××××.net, excerpted below, on Tue, |
| 3 |
13 Jun 2006 17:32:38 -0400: |
| 4 |
|
| 5 |
> What we *are* arguing against is having something in a |
| 6 |
> non-project-specific overlay, that is not maintained by the project in |
| 7 |
> question, and has *specifically* been rejected by the project in |
| 8 |
> question. This sort of thing should *never* make it into the sunrise |
| 9 |
> overlay, since it has been rejected. |
| 10 |
|
| 11 |
But as Stuart Herbert pointed out, a project can be self-authorized, by |
| 12 |
the current rules. Project Sunrise therefore didn't /need/ permission to |
| 13 |
come into existence and set up its own overlay. The announcement here, |
| 14 |
while perhaps it /should/ have been discussed as a proposal first, |
| 15 |
therefore didn't break the rules as they are now. |
| 16 |
|
| 17 |
Meanwhile, the Project Sunrise overlay /is/ a project specific overlay, |
| 18 |
and /is/ maintained by the project in question (Sunrise). That has been |
| 19 |
specifically stated in the Project Sunrise formulation. |
| 20 |
|
| 21 |
Furthermore, there's specific allowance for competing projects, and as |
| 22 |
Stuart again points out, ebuilds form herds which are maintained by |
| 23 |
projects, and once a project rejects the ebuild, it can then be picked up |
| 24 |
by another developer or project, in which case the project that rejected |
| 25 |
it is no more responsible for it except that they can continue to refuse |
| 26 |
that it be in that project. |
| 27 |
|
| 28 |
-- |
| 29 |
Duncan - List replies preferred. No HTML msgs. |
| 30 |
"Every nonfree program has a lord, a master -- |
| 31 |
and if you use the program, he is your master." Richard Stallman |
| 32 |
|
| 33 |
-- |
| 34 |
gentoo-dev@g.o mailing list |
Archives