From 014782e819335d7ae6ca90bcbf94d072619b0f2b Mon Sep 17 00:00:00 2001 From: Kendall Nelson Date: Sun, 29 Jul 2018 06:58:55 -0700 Subject: [PATCH] Split Governance and Releases Sections This patch splits release content out from the governance section so that its a little less daunting to new contributors. It also then matches the way the exercises are split up in the training guides. Change-Id: I0494b29bb5bc4beaf1410b68aed6833309f1fbac --- doc/source/code-and-documentation/index.rst | 1 + doc/source/common/governance.rst | 69 ------------------- doc/source/common/releases.rst | 75 +++++++++++++++++++++ doc/source/operators/index.rst | 1 + doc/source/users/index.rst | 1 + 5 files changed, 78 insertions(+), 69 deletions(-) create mode 100644 doc/source/common/releases.rst diff --git a/doc/source/code-and-documentation/index.rst b/doc/source/code-and-documentation/index.rst index 8373e4b..b467aa1 100644 --- a/doc/source/code-and-documentation/index.rst +++ b/doc/source/code-and-documentation/index.rst @@ -11,6 +11,7 @@ Code & Documentation Contributor Guide /common/irc /common/accounts /common/governance + /common/releases /common/events /common/task-tracking /common/git diff --git a/doc/source/common/governance.rst b/doc/source/common/governance.rst index 0e40390..ad5d0a9 100644 --- a/doc/source/common/governance.rst +++ b/doc/source/common/governance.rst @@ -179,72 +179,3 @@ Community members who have engaged in community functions listed in the are considered to be Active User Contributors. The User Committee chairs are elected from and by the group of AUCs. - -Releases -======== - -OpenStack has a 6-month long release cadence with different release models that -projects can choose to follow. - -Release Models --------------- - -OpenStack consists of a large number of projects that form the main components -of an OpenStack cloud, from client libraries to lifecycle management -services. The different projects are different in nature which implies -different `release models -`_ to follow. - -The currently available options are the following: - -* `cycle-with-milestones - `_ -* `cycle-with-intermediary - `_ -* `cycle-trailing - `_ -* `independent - `_ -* `untagged - `_ - -Release Schedule and Planning ------------------------------ - -The majority of the official OpenStack projects follow the release schedule -set by the Release Management Team. - -The 6-month cycle is divided into three milestones and a usually one-month long -stabilization period with release candidates. - -The first period of a cycle includes more focus on planning, which is why the -PTGs are scheduled right after the releases. This is the phase when you should -upload your specs for review and use the mailing list, project channels and -meetings on IRC to discuss any parts of your design that might be in question. - -After the first milestone, some projects focus more on the development and bug -fixing activities, while other projects might still accept new ideas to -implement in that cycle. - -The third period of a release is focusing on finishing the implementation and -testing of new functionality added during the release. You need to esnure to -add new tests in Tempest and have documentation covered as well before the -third milestone. During this phase the core review team can choose to focus on -higher priority features only. They make their decision about priorities either -at the PTG or soon after, some time before the first milestone of a release. - -Some projects also have different dates through a release cycles as internal, -project-specific deadlines, like spec-freeze or code-freeze. You need to make -sure you are aware of the freeze dates which you can find on the `release -schedule page `_. - -After the third milestone the community is focusing on stabilizing the release -by putting more emphasis on testing and fixing bugs. The projects following -the release cycle have their release candidates tagged after the third -milestone. There are no limits to release candidates, but the goal is to keep -the number low and fix all the critical issues that got identified by -milestone-3. - -Having the main projects following the release cycle ensures that all these -projects release at the same time so these can be picked up by downstream -teams to package and further distribute. diff --git a/doc/source/common/releases.rst b/doc/source/common/releases.rst new file mode 100644 index 0000000..d1662d6 --- /dev/null +++ b/doc/source/common/releases.rst @@ -0,0 +1,75 @@ +######## +Releases +######## + +OpenStack has a 6-month long release cadence with different release models that +projects can choose to follow. + +This section allows you to: + +* Understand the different release models that OpenStack components follow +* Know the structure of the different release models and how to work + effectively in those to influence the future of OpenStack + +Release Models +-------------- + +OpenStack consists of a large number of projects that form the main components +of an OpenStack cloud, from client libraries to lifecycle management +services. The different projects are different in nature which implies +different `release models +`_ to follow. + +The currently available options are the following: + +* `cycle-with-milestones + `_ +* `cycle-with-intermediary + `_ +* `cycle-trailing + `_ +* `independent + `_ +* `untagged + `_ + +Release Schedule and Planning +----------------------------- + +The majority of the official OpenStack projects follow the release schedule +set by the Release Management Team. + +The 6-month cycle is divided into three milestones and a usually one-month long +stabilization period with release candidates. + +The first period of a cycle includes more focus on planning, which is why the +PTGs are scheduled right after the releases. This is the phase when you should +upload your specs for review and use the mailing list, project channels and +meetings on IRC to discuss any parts of your design that might be in question. + +After the first milestone, some projects focus more on the development and bug +fixing activities, while other projects might still accept new ideas to +implement in that cycle. + +The third period of a release is focusing on finishing the implementation and +testing of new functionality added during the release. You need to esnure to +add new tests in Tempest and have documentation covered as well before the +third milestone. During this phase the core review team can choose to focus on +higher priority features only. They make their decision about priorities either +at the PTG or soon after, some time before the first milestone of a release. + +Some projects also have different dates through a release cycles as internal, +project-specific deadlines, like spec-freeze or code-freeze. You need to make +sure you are aware of the freeze dates which you can find on the `release +schedule page `_. + +After the third milestone the community is focusing on stabilizing the release +by putting more emphasis on testing and fixing bugs. The projects following +the release cycle have their release candidates tagged after the third +milestone. There are no limits to release candidates, but the goal is to keep +the number low and fix all the critical issues that got identified by +milestone-3. + +Having the main projects following the release cycle ensures that all these +projects release at the same time so these can be picked up by downstream +teams to package and further distribute. diff --git a/doc/source/operators/index.rst b/doc/source/operators/index.rst index fe9ed34..6bf1a32 100644 --- a/doc/source/operators/index.rst +++ b/doc/source/operators/index.rst @@ -16,3 +16,4 @@ Operators' Contributor Guide /common/setup-gerrit /operators/participate /common/governance + /common/releases diff --git a/doc/source/users/index.rst b/doc/source/users/index.rst index 6e2106c..5ad8595 100644 --- a/doc/source/users/index.rst +++ b/doc/source/users/index.rst @@ -14,3 +14,4 @@ Users' Contributor Guide /common/git /common/setup-gerrit /common/governance + /common/releases