opendev/infra-manual
Code Issues Proposed changes

Merge "Update to reflect recent governance changes"

Browse Source
This commit is contained in:
Jenkins 2015-02-17 20:20:14 +00:00 committed by Gerrit Code Review
commit 58eac23fb3
3 changed files with 16 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
doc/source/creators.rst
View File

@ -197,21 +197,21 @@ and click "Add Role".
Add Project to the Governance Repository Add Project to the Governance Repository
======================================== ========================================
Each project managed by an official program in OpenStack needs to be Each project managed by an official OpenStack project team needs to be
listed in ``reference/programs.yaml`` in the ``openstack/governance`` listed in ``reference/projects.yaml`` in the ``openstack/governance``
repository to indicate who owns the project so we know where ATCs repository to indicate who owns the project so we know where ATCs
voting rights extend. voting rights extend.
If your project is under the ``stackforge`` section of the git If your project is under the ``stackforge`` section of the git
repository structure, you can skip this step. repository structure, you can skip this step.
Find the appropriate section in ``reference/programs.yaml`` and add Find the appropriate section in ``reference/projects.yaml`` and add
the new project to the list. For example, to add a new Oslo library the new project to the list. For example, to add a new Oslo library
edit the "Common Libraries" section:: edit the "Oslo" section::
Common Libraries: Oslo:
codename: Oslo
ptl: Doug Hellmann (dhellmann) ptl: Doug Hellmann (dhellmann)
service: Common libraries
mission: mission:
To produce a set of python libraries containing code shared by OpenStack To produce a set of python libraries containing code shared by OpenStack
projects. The APIs provided by these libraries should be high quality, projects. The APIs provided by these libraries should be high quality,

16
doc/source/developers.rst
View File

@ -184,7 +184,7 @@ Development Workflow
Working on Bugs Working on Bugs
--------------- ---------------
Bug reports for a program or project are tracked on Launchpad at Bug reports for a project are generally tracked on Launchpad at
https://bugs.launchpad.net/<projectname>. Contributors may review these https://bugs.launchpad.net/<projectname>. Contributors may review these
reports regularly when looking for work to complete. reports regularly when looking for work to complete.
@ -226,9 +226,9 @@ section of the OpenStack Git Commit Good Practices wiki page.
Working on Specifications and Blueprints Working on Specifications and Blueprints
---------------------------------------- ----------------------------------------
Many OpenStack projects and programs have a <project>-specs respository which Many OpenStack projects teams have a <projectteam>-specs respository which
is used to hold approved design specifications for additions and changes to is used to hold approved design specifications for additions and changes to
the project or program. the project teams code repositories.
The layout of the repository will typically be something like:: The layout of the repository will typically be something like::
@ -242,7 +242,7 @@ and which have already been implemented:
You can typically find an example spec in ``specs/template.rst``. You can typically find an example spec in ``specs/template.rst``.
Check the repository for the project or program you're working on for specifics Check the repository for the project team you're working on for specifics
about repository organization. about repository organization.
Specifications are proposed for a given release by adding them to the Specifications are proposed for a given release by adding them to the
@ -255,12 +255,12 @@ quick, but even if something was previously approved, it should be re-reviewed
to make sure it still makes sense as written. to make sure it still makes sense as written.
Historically, Launchpad blueprints were used to track the implementation of Historically, Launchpad blueprints were used to track the implementation of
these significant features and changes in OpenStack. For many projects and these significant features and changes in OpenStack. For many project teams,
programs, these Launchpad blueprints are still used for tracking the current these Launchpad blueprints are still used for tracking the current
status of a specification. For more information, see `the Blueprints wiki page status of a specification. For more information, see `the Blueprints wiki page
<https://wiki.openstack.org/wiki/Blueprints>`_. <https://wiki.openstack.org/wiki/Blueprints>`_.
View all approved project and program specifications at View all approved project teams specifications at
http://specs.openstack.org/. http://specs.openstack.org/.
Starting a Change Starting a Change
@ -540,7 +540,7 @@ If a change fails tests in Jenkins, please follow the steps below:
error isn't there, then: error isn't there, then:
2. Identify which project(s) are affected, and search for a related 2. Identify which project(s) are affected, and search for a related
bug on Launchpad. You can search for bugs affecting all OpenStack bug on Launchpad. You can search for bugs affecting all OpenStack
Programs here: https://bugs.launchpad.net/openstack/ If you do Projects here: https://bugs.launchpad.net/openstack/ If you do
not find an existing bug, file a new one (be sure to include not find an existing bug, file a new one (be sure to include
the error message and a link to the logs for the failure). If the the error message and a link to the logs for the failure). If the
problem is due to an infrastructure problem (such as Jenkins or problem is due to an infrastructure problem (such as Jenkins or

4
doc/source/drivers.rst
View File

@ -222,14 +222,14 @@ state of the tree.
Targeting Blueprints Targeting Blueprints
==================== ====================
Blueprints for a program or project are posted to Blueprints for a project are generally posted to
https://blueprints.launchpad.net/<projectname>. Project drivers need to review https://blueprints.launchpad.net/<projectname>. Project drivers need to review
blueprints regularly and assign them to a target. For each release there are three blueprints regularly and assign them to a target. For each release there are three
milestones. Based on interactions with the proposer and/or assignee of the blueprint, milestones. Based on interactions with the proposer and/or assignee of the blueprint,
the project driver assigns the blueprint to a milestone the project driver assigns the blueprint to a milestone
(release-1, release-2 or release-3) or defers it to a later release. (release-1, release-2 or release-3) or defers it to a later release.
Many projects have repositories entitled <project>-specs. If a project has a spec Many projects have repositories entitled <projectteam>-specs. If a project has a spec
repo, a spec needs to be submitted and linked to the launchpad blueprint. The spec repo, a spec needs to be submitted and linked to the launchpad blueprint. The spec
needs to be reviewed and approved prior to the launchpad blueprint being targeted to needs to be reviewed and approved prior to the launchpad blueprint being targeted to
a milestone. a milestone.