Jump to: navigation, search

Difference between revisions of "Project Group Management"

(launchpad)
m (Gerrit: fix urls to point to opendev.org)
 
(9 intermediate revisions by 5 users not shown)
Line 1: Line 1:
__NOTOC__
 
  
<pre><nowiki>#!wiki caution
+
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.
'''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.
 
</nowiki></pre>
 
 
 
 
 
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 a minimal amount of duplicate information in them.
 
  
 
== Gerrit ==
 
== 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''').
+
There are three typical groups of users per-project who are managed in Gerrit: a '''core''' group, a '''milestone''' group and a '''ptl''' 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''), a '''foo-milestone''' group responsible for deciding what patches are merged to '''foo''''s proposed/* branch in preparation for the next stable release, and a '''foo-ptl''' group (usually with a single member--the project technical lead) responsible for things like tagging client releases. The groups for server projects are typically shared by corresponding client projects (for example, '''python-fooclient''').
  
Group membership is self-managed by existing group members through the Gerrit WebUI under [https://review.openstack.org/#/admin/groups/ 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.
+
Group membership is self-managed by existing group members through the Gerrit WebUI under [https://review.opendev.org/#/admin/groups/ 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 somewhat 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 [https://github.com/openstack-infra/config/tree/master/modules/openstack_project/files/gerrit/acls openstack-infra/config] repository.
+
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 '''milestone''' group the responsibility of cutting branches and tagging release commits instead of having a '''ptl''' group. The configuration files corresponding to these ACLs are all managed in the [https://opendev.org/openstack/project-config/src/branch/master/gerrit/acls/openstack openstack/project-config] repository.
  
 
== Launchpad ==
 
== Launchpad ==
Line 22: Line 14:
 
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.
 
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.
+
Team membership is managed by members marked with an ''Administrator'' status through the Launchpad WebUI. Official OpenStack projects must make the ''OpenStack Admins'' team (~openstack-admins) the ''Owner'' of their Launchpad teams. They should also add the ''release team'' (~openstack-release) to their '''-drivers''' team.

Latest revision as of 16:20, 25 February 2020

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 three typical groups of users per-project who are managed in Gerrit: a core group, a milestone group and a ptl 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), a foo-milestone group responsible for deciding what patches are merged to foo's proposed/* branch in preparation for the next stable release, and a foo-ptl group (usually with a single member--the project technical lead) responsible for things like tagging client releases. The groups for server projects are typically 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 milestone group the responsibility of cutting branches and tagging release commits instead of having a ptl group. The configuration files corresponding to these ACLs are all managed in the openstack/project-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. Official OpenStack projects must make the OpenStack Admins team (~openstack-admins) the Owner of their Launchpad teams. They should also add the release team (~openstack-release) to their -drivers team.