1 |
Marius Mauch wrote: |
2 |
|
3 |
> On Sat, 10 Jun 2006 13:37:15 +0200 |
4 |
> Markus Ullmann <jokey@g.o> wrote: |
5 |
> |
6 |
>> Okay, so after figuring out open problems (thanks to kloeri and |
7 |
>> various other people for help here), we now have a resolution that |
8 |
>> should satisfy all involved parties here. This should adress |
9 |
>> dostrow's demands as well. |
10 |
>> |
11 |
>> 1) m-w / m-n requirement |
12 |
>> |
13 |
>> Only ebuilds that are reported to bugzie (valid bug#) and set to |
14 |
>> maintainer-wanted are allowed here as well as maintainer-needed ones. |
15 |
>> |
16 |
>> maintainer-needed are only allowed if they're removed from the tree |
17 |
>> and moved over to sunrise (and thus end up as maintainer-wanted |
18 |
>> again). |
19 |
> |
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 |
> |
36 |
> One more rule I'd like to see (should be obvious, but better to write |
37 |
> it down): |
38 |
> |
39 |
> People who commit to a certain project/ebuild have to be on the CC |
40 |
> list of the relevant bug report(s) and any important commits should be |
41 |
> documented on the bugs (including the revision of/link to the commit). |
42 |
I have not made it a rule yet to prevent whitespacing and updates for minor |
43 |
changes, also I would like to leave things like that to the people to |
44 |
decide to prevent that too many rules lock us in. |
45 |
How far would you want to go? Update for "I have removed some quotes" for "I |
46 |
have made a version bump"? |
47 |
Currently it is written down as follows: |
48 |
|
49 |
http://overlays.gentoo.org/proj/sunrise/wiki/HowToCommit, point 6 |
50 |
--snip-- |
51 |
6) For later updates to the package in the overlay it is still considered |
52 |
good style to update the bug and link to the changes, for exmaple: |
53 |
|
54 |
I added some sed calls, it should build with --as-needed now |
55 |
http://overlays.gentoo.org/svn/proj/sunrise/sys-apps/openguru/openguru-1.ebuild |
56 |
--snap-- |
57 |
I think it should be at least changed from a suggestion to a "you need to |
58 |
for updates of .." |
59 |
So,, my question, how far do you want them to go here? |
60 |
|
61 |
- Stefan |
62 |
|
63 |
|
64 |
-- |
65 |
gentoo-dev@g.o mailing list |