Jump to: navigation, search

Difference between revisions of "Project Group Management"

m (Text replace - "__NOTOC__" to "")
Line 1: Line 1:
__NOTOC__
+
 
  
 
<pre><nowiki>#!wiki caution
 
<pre><nowiki>#!wiki caution

Revision as of 23:30, 17 February 2013


#!wiki caution
'''Future Instructions'''

These are preview instructions for upcoming changes in the project group management process, and are not intended to be usable until 21:00 UTC on February 24, 2013 at the conclusion of the new CLA implementation maintenance window.


Group management for OpenStack and StackForge projects happens primarily in two places, Gerrit (for code review) and Launchpad (for bugs and blueprints). These systems are not interconnected and as such there is still a small amount of duplicate information kept in them.

Gerrit

There are two typical groups of users per-project who are managed in Gerrit: a core group and a drivers group. For an official OpenStack project foo, Gerrit will usually have a foo-core group consisting of core contributors delegated the responsibility of merging suitable code contributions to foo's master branch (and possibly marking others' patches Work in Progress or Ready for Review), and a foo-drivers group responsible for deciding what patches are merged to foo's milestone-proposed branch in preparation for the next stable release. In many cases the groups for server projects are shared by corresponding client projects (for example, python-fooclient).

Group membership is self-managed by existing group members through the Gerrit WebUI under Admin..Groups. Follow the link corresponding to the group name, then select Members in the left sidebar. To add a new member, start typing the Name or Email by which the user is known into the Members field in the right pane until a suitable match appears below it, then select it and click the Add button. To remove an existing member, select the checkbox to the left of the member's name in the roster and then click the Delete button.

Groups for StackForge (and non-core OpenStack) projects are encouraged to follow the same pattern but are less standardized--for example one might have only a core group or another might assign its drivers group the responsibility of cutting branches and tagging release commits. The configuration files corresponding to these ACLs are all managed in the openstack-infra/config repository.

Launchpad

There are two typical teams of users per-project who are managed in Launchpad: a bugs team and a drivers team. For an official OpenStack project foo, Launchpad will usually have a foo-bugs team as its Bug Supervisor responsible for assigning and targeting foo's bug reports, and a foo-drivers team as its Driver approving foo's blueprints for the next stable release.

Team membership is managed by members marked with an Administrator status through the Launchpad WebUI. For proper integration with OpenStack's Continuous Integration systems, the bugs team needs to have the OpenStack Hudson (openstack-hudson) user as a member. Official OpenStack projects also must make the OpenStack Admins team the Owner of their Launchpad teams.