Stefan Schweizer schrieb:
Marius Mauch wrote:

On Sat, 10 Jun 2006 13:37:15 +0200
Markus Ullmann <[EMAIL PROTECTED]> wrote:

Okay, so after figuring out open problems (thanks to kloeri and
various other people for help here), we now have a resolution that
should satisfy all involved parties here. This should adress
dostrow's demands as well.

1) m-w / m-n requirement

Only ebuilds that are reported to bugzie (valid bug#) and set to
maintainer-wanted are allowed here as well as maintainer-needed ones.

maintainer-needed are only allowed if they're removed from the tree
and moved over to sunrise (and thus end up as maintainer-wanted
again).
5) commit access to the overlay

We implement two levels of commit rights:

1. As there are people out there who just want to maintain one app for
start, the ebuild should reach a level that project devs are fine with
it, then the user is given permission to commit on that single app. An
automated check makes sure that he doesn't commit anywhere else. If
violations arise, the access is revoked immediately.

2. People who contribute good ebuilds over a certain period of time
are allowed upon decision by project devs to actively help
maintaining the project. They'll be given commit rights for the
project then. Same frome above applies here: If we notice any abuse,
we revoke access immediately.
One more rule I'd like to see (should be obvious, but better to write
it down):

People who commit to a certain project/ebuild have to be on the CC
list of the relevant bug report(s) and any important commits should be
documented on the bugs (including the revision of/link to the commit).
I have not made it a rule yet to prevent whitespacing and updates for minor
changes, also I would like to leave things like that to the people to
decide to prevent that too many rules lock us in.
How far would you want to go? Update for "I have removed some quotes" for "I
have made a version bump"?

Functional changes, bugfixes, etc. Let people use common sense there. The intention is simply that people watching the bug don't have to track the overlay as well to get notifications of important changes (like a bugfix that prevented them from using the ebuild previously). Certainly you wouldn't consider whitespace changes or coding style updates as an *important*, would you?

Marius
--
gentoo-dev@gentoo.org mailing list

Reply via email to