simultaneous_release_process_and_guidelines
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
simultaneous_release_process_and_guidelines [2014/11/12 14:26] David Lenrow |
simultaneous_release_process_and_guidelines [2014/12/01 21:51] David Lenrow |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | **UNDER CONSTRUCTION** | + | ====== **UNDER CONSTRUCTION ** ====== |
| + | |||
| + | ===== Draft Schedule Spreadsheets ===== | ||
| + | |||
| + | |||
| + | {{:tc:141001:opnfv-sched-sr2-1.xlsx|}} | ||
| + | |||
| + | {{:tc:141001:opnfv-sched-sr1-fast-platform_.xlsx|}} | ||
| + | |||
| + | ===== Meeting Minutes ===== | ||
| + | ==== 11/26/2014 ==== | ||
| + | http://ircbot.wl.linuxfoundation.org/meetings/opnfv-meeting/2014/opnfv-meeting.2014-11-26-15.19.html | ||
| + | |||
| + | Full logs from IRC (although I think they are mostly just #infos) are | ||
| + | here: | ||
| + | |||
| + | http://ircbot.wl.linuxfoundation.org/meetings/opnfv-meeting/2014/opnfv-meeting.2014-11-26-15.19.log.html | ||
| - | <html> | ||
| - | This is some <span style="color:red;font-size:150%;">inline HTML</span> | ||
| - | </html> | ||
| ====== Simultaneous Release Process for OPNFV ====== | ====== Simultaneous Release Process for OPNFV ====== | ||
| Line 13: | Line 27: | ||
| * Pull tested upstream stable release artifacts (Trust upstream infra works) | * Pull tested upstream stable release artifacts (Trust upstream infra works) | ||
| Then | Then | ||
| - | * Build local tools, and test infrastructure | + | * Build local tools, projects, and test infrastructure |
| * Run system tests (CI Test) across collective components. | * Run system tests (CI Test) across collective components. | ||
| * Identify and report defects in upstream components | * Identify and report defects in upstream components | ||
| Line 86: | Line 100: | ||
| - | Sept 2015 | + | == Sept 2015 == |
| 6 Months after our first and 3 months after Kilo we bring second OPNFV SR. | 6 Months after our first and 3 months after Kilo we bring second OPNFV SR. | ||
| - | Spring 2016 | + | == Spring 2016 == |
| TBD | TBD | ||
| - | Fall 2016 | + | == Fall 2016 == |
| TBD | TBD | ||
| - | Schedule Milestones | + | == Schedule Milestones == |
| To avoid major surgery during the time when test/fix cycle is trying to converge we will define “quiet” times imposing constraints like API Freeze, Feature Freeze, and a series of release candidates. Dates for these milestones will be backed out of the release target dates and based on estimates of the work required. In a true “continuous delivery” environment it may turn out that the delta between grabbing the head of dev tree and shipping an SR may approach zero. The initial release will probably need to support some element of non-automated testing and will need an appropriate cycle time and number of cycles to get to release quality. | To avoid major surgery during the time when test/fix cycle is trying to converge we will define “quiet” times imposing constraints like API Freeze, Feature Freeze, and a series of release candidates. Dates for these milestones will be backed out of the release target dates and based on estimates of the work required. In a true “continuous delivery” environment it may turn out that the delta between grabbing the head of dev tree and shipping an SR may approach zero. The initial release will probably need to support some element of non-automated testing and will need an appropriate cycle time and number of cycles to get to release quality. | ||
| - | Basic Layers in OPNFV CI Build | + | == Basic Layers in OPNFV CI Build == |
| At any given point in OPNFV release cycle we can expect to combine a number of different layers source module and resulting artifacts to provide the OPNFV value add. | At any given point in OPNFV release cycle we can expect to combine a number of different layers source module and resulting artifacts to provide the OPNFV value add. | ||
| 1. Stable branches and artifacts from upstream projects | 1. Stable branches and artifacts from upstream projects | ||
| Line 102: | Line 121: | ||
| 3. OPNFV native projects which will continue to live in the OPNFV repo and be built as value add on top of upstream projects. | 3. OPNFV native projects which will continue to live in the OPNFV repo and be built as value add on top of upstream projects. | ||
| Functionality and logic will move between 1 and 2 but should be transparent to the function of the resulting artifacts. | Functionality and logic will move between 1 and 2 but should be transparent to the function of the resulting artifacts. | ||
| - | Requirements for Participation | + | == Requirements for Participation == |
| - | In order to participate in the simultaneous release, a project must do the following things. | + | |
| - | 1. Planning | + | == In order to participate in the simultaneous release, a project must do the following things. == |
| - | • Projects must declare their intent to participate in the Simultaneous Release by M1. This is accomplished by adding the project to the table in participating projects and sending the first milestone readout mail. | + | |
| - | • Participating projects must publish a candidate Release Plan by M1 and declare their final Release Plan by M2 | + | === Planning === |
| - | • Participating project Release Plans must contain Milestones that minimally line up with the Simultaneous Release Plan Milestones | + | |
| - | 2. Leadership & Communication | + | * Projects must declare their intent to participate in the Simultaneous Release by M1. This is accomplished by adding the project to the table in participating projects and sending the first milestone readout mail. |
| - | • Each project must elect a Project Lead as described in the TSC charter, section 7. | + | * Participating projects must publish a candidate Release Plan by M1 and declare their final Release Plan by M2 |
| - | • Phil Robb will help projects with this process and it must be completed by M1. | + | * Participating project Release Plans must contain Milestones that minimally line up with the Simultaneous Release Plan Milestones |
| - | • The results of the election, and other changes to the project lead during this release, should be reported by | + | |
| - | 1. Updating the project facts template for the project on its main wiki page | + | |
| - | 2. Updating the participating projects table of this release | + | |
| - | 3. Sending an e-mail the <project>-dev, release, and tsc lists | + | === Leadership & Communication === |
| - | • The Project Lead is expected to be responsible for the the project meeting deadlines, interacting with other projects, and interacting with the TSC | + | * Each project must elect a Project Lead (as described in the TSC charter ?) |
| - | • The Project Lead will be subscribed to the release mailing list and must respond to requests send to the a timely fashion, i.e., 48 hours excluding weekends | + | * LF will help projects with this process and it must be completed by M1. |
| - | • If a Project Lead is not be able to do so, they should (i) have somebody else stand in and do this on their behalf, (ii) send a mail to the release mailing list indicating this and the time period, and (iii) note the same information in the participating projects section of the release plan. | + | * The results of the election, and other changes to the project lead during this release, should be reported by |
| - | • All release-critical correspondence will have a subject line containing "PLEASE RESPOND BY <DATE> <UTC-TIME>" | + | |
| - | • Please limit traffic to correspondence directly relating to the release | + | - Updating the project facts template for the project on its main wiki page |
| - | • The TSC should collect response time metrics for projects both to inform our planning and for project maturity going forward. | + | - Updating the participating projects table of this release |
| - | 3. Service Release Participation | + | - Sending an e-mail the <project>-dev, release, and tsc lists |
| - | • All projects participating in the release are also required to participate in the stability releases after the formal release | + | |
| - | 4. Modularity | + | |
| - | • Modules that are not intended to interface with the controller via REST/other RPC mechanism must be OSGI bundles | + | The Project Lead is expected to be responsible for the the project meeting deadlines, interacting with other projects, and interacting with the TSC |
| - | • OSGI bundles should be reasonably granular | + | The Project Lead will be subscribed to the release mailing list and must respond to requests send to the a timely fashion, i.e., 48 hours excluding weekends |
| - | 5. Quality | + | * If a Project Lead is not be able to do so, they should (i) have somebody else stand in and do this on their behalf, (ii) send a mail to the release mailing list indicating this and the time period, and (iii) note the same information in the participating projects section of the release plan. |
| - | • No later than M2 as part of the Gerrit/Jenkins merge process participating projects must push their binary artifacts to the Nexus repository | + | * All release-critical correspondence will have a subject line containing "PLEASE RESPOND BY <DATE> <UTC-TIME>" |
| - | • No later than M2, each project must have a Jenkins Job which rebuilds and retests to an appropriate level when a project it depends on publishes new artifacts | + | * Please limit traffic to correspondence directly relating to the release |
| - | • No later that M2, each project primarily written in Java must be reporting unit test coverage via sonar | + | * The TSC should collect response time metrics for projects both to inform our planning and for project maturity going forward. |
| - | 6. Documentation | + | == Service Release Participation == |
| - | • Each participating project is expected to identify the kinds of documentation that would be useful (e.g., installation guide, user guide, developer guide) and provide them as part of the release. | + | * Unordered List ItemAll projects participating in the release are also required to participate in the stability releases after the formal release |
| - | 7. Code Hygiene | + | == Modularity == |
| - | • No uses of System.out.println in non-test code. | + | * Hard to generalize as a midstream/glue project |
| - | • No dependencies on 3rd party snapshot versions | + | |
| - | • Willing to use agreed-upon versions for dependencies (both 3rd party and ODL), i.e., to eliminate version skew | + | == Quality == |
| - | 8. Distribution | + | |
| - | • All projects must support an X86? PC Bios? What can we assume about exec environment? | + | * No later than M2 as part of the Gerrit/Jenkins merge process participating projects must push their binary artifacts to the Nexus repository |
| - | 9. Meeting Deadlines | + | * No later than M2, each project must have a Jenkins Job which rebuilds and retests to an appropriate level when a project it depends on publishes new artifacts |
| - | • All projects are expected to meet the deadlines laid out in the schedule below. | + | * No later that M2, each project primarily written in Java must be reporting unit test coverage via sonar |
| - | • If a project cannot make a deadline, the project lead must write a summary of what was missed, why, the course correction that will be taken, and it's impact on other projects. | + | |
| - | • For offset two project this is mainly intended to be reflective and to help inform the release process | + | == Documentation == |
| - | • For offset zero and offset two projects, this should be completed with 24 hours of missing the deadline and must be presented to the TSC at the first TSC meeting after the deadline | + | |
| - | • All Milestone deliverables will be verified by the OPNFV release management staff and/or the TSC. | + | * Unordered List ItemEach participating project is expected to identify the kinds of documentation that would be useful (e.g., installation guide, user guide, developer guide) and provide them as part of the release. |
| - | • NOTE: For deliverables defined only in the project's release plan—and not as a requirement in this document—the release management staff and/or TSC will verify that the status of the deliverables has been reported. OPNFV release management staff and/or the TSC may also, but are not required to, verify the delivered functionality. | + | == Code Hygiene == |
| + | * No uses of System.out.println in non-test code. | ||
| + | * No dependencies on 3rd party snapshot versions | ||
| + | * Willing to use agreed-upon versions for dependencies (both 3rd party and ODL), i.e., to eliminate version skew | ||
| + | == Distribution == | ||
| + | |||
| + | * Unordered List ItemAll projects must support an X86? PC Bios? What can we assume about exec environment? | ||
| + | == Meeting Deadlines == | ||
| + | |||
| + | * All projects are expected to meet the deadlines laid out in the schedule below. | ||
| + | * If a project cannot make a deadline, the project lead must write a summary of what was missed, why, the course correction that will be taken, and it's impact on other projects. | ||
| + | * For offset two project this is mainly intended to be reflective and to help inform the release process | ||
| + | * For offset zero and offset two projects, this should be completed with 24 hours of missing the deadline and must be presented to the TSC at the first TSC meeting after the deadline | ||
| + | * All Milestone deliverables will be verified by the OPNFV release management staff and/or the TSC. | ||
| + | * NOTE: For deliverables defined only in the project's release plan—and not as a requirement in this document—the release management staff and/or TSC will verify that the status of the deliverables has been reported. OPNFV release management staff and/or the TSC may also, but are not required to, verify the delivered functionality. | ||
| Milestones, Release Candidates, and Service Releases[edit] | Milestones, Release Candidates, and Service Releases[edit] | ||
| • Milestones are spaced roughly 4 weeks apart taking into account significant holidays. | • Milestones are spaced roughly 4 weeks apart taking into account significant holidays. | ||
simultaneous_release_process_and_guidelines.txt · Last modified: 2016/03/02 15:07 by Christopher Price
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
