| 1 |
Stefan Schweizer schrieb: |
| 2 |
> Marius Mauch wrote: |
| 3 |
> |
| 4 |
>> On Sat, 10 Jun 2006 13:37:15 +0200 |
| 5 |
>> Markus Ullmann <jokey@g.o> wrote: |
| 6 |
>> |
| 7 |
>>> Okay, so after figuring out open problems (thanks to kloeri and |
| 8 |
>>> various other people for help here), we now have a resolution that |
| 9 |
>>> should satisfy all involved parties here. This should adress |
| 10 |
>>> dostrow's demands as well. |
| 11 |
>>> |
| 12 |
>>> 1) m-w / m-n requirement |
| 13 |
>>> |
| 14 |
>>> Only ebuilds that are reported to bugzie (valid bug#) and set to |
| 15 |
>>> maintainer-wanted are allowed here as well as maintainer-needed ones. |
| 16 |
>>> |
| 17 |
>>> maintainer-needed are only allowed if they're removed from the tree |
| 18 |
>>> and moved over to sunrise (and thus end up as maintainer-wanted |
| 19 |
>>> again). |
| 20 |
>>> 5) commit access to the overlay |
| 21 |
>>> |
| 22 |
>>> We implement two levels of commit rights: |
| 23 |
>>> |
| 24 |
>>> 1. As there are people out there who just want to maintain one app for |
| 25 |
>>> start, the ebuild should reach a level that project devs are fine with |
| 26 |
>>> it, then the user is given permission to commit on that single app. An |
| 27 |
>>> automated check makes sure that he doesn't commit anywhere else. If |
| 28 |
>>> violations arise, the access is revoked immediately. |
| 29 |
>>> |
| 30 |
>>> 2. People who contribute good ebuilds over a certain period of time |
| 31 |
>>> are allowed upon decision by project devs to actively help |
| 32 |
>>> maintaining the project. They'll be given commit rights for the |
| 33 |
>>> project then. Same frome above applies here: If we notice any abuse, |
| 34 |
>>> we revoke access immediately. |
| 35 |
>> One more rule I'd like to see (should be obvious, but better to write |
| 36 |
>> it down): |
| 37 |
>> |
| 38 |
>> People who commit to a certain project/ebuild have to be on the CC |
| 39 |
>> list of the relevant bug report(s) and any important commits should be |
| 40 |
>> documented on the bugs (including the revision of/link to the commit). |
| 41 |
> I have not made it a rule yet to prevent whitespacing and updates for minor |
| 42 |
> changes, also I would like to leave things like that to the people to |
| 43 |
> decide to prevent that too many rules lock us in. |
| 44 |
> How far would you want to go? Update for "I have removed some quotes" for "I |
| 45 |
> have made a version bump"? |
| 46 |
|
| 47 |
Functional changes, bugfixes, etc. Let people use common sense there. |
| 48 |
The intention is simply that people watching the bug don't have to track |
| 49 |
the overlay as well to get notifications of important changes (like a |
| 50 |
bugfix that prevented them from using the ebuild previously). |
| 51 |
Certainly you wouldn't consider whitespace changes or coding style |
| 52 |
updates as an *important*, would you? |
| 53 |
|
| 54 |
Marius |
| 55 |
-- |
| 56 |
gentoo-dev@g.o mailing list |
Archives