PROJECT LIFECYCLE & RELEASES
TABLE OF CONTENTS
Overview Project Types and Lifecycle Mature Release Process Simultaeous Release Cycle Code Flow Bootstrap Process Intra Project Decision Making
This document covers the ODP Project Lifecycle. The project lifecycle defined here allows for
- Simple project incubation
- Healthy mature projects
- Core projects
- Project hierarchy so as to allow the emergence of thematic sub-communities
The release cycle proposed for mature projects
- Is simple and light weight
- Provides sufficient visibility to allow projects to coordinate with one another and flock naturally.
The simultaneous release process proposed lays out a simple process for projects to formally flock together toward a single unified, integrated, mutually interoperating release.
This document also covers the code lifecycle.
2.1 Project Types
| Project Type | Description |
| Proposal | Doesn’t really exist yet, has no real project resources, but is proposed |
| Incubation | Project has resources, but is recognized to be nascent |
| Mature | Project is a fully functioning, successful open source project |
| Core | Project is core to OpenDaylight |
| Top Level | Project has sub projects that are thematically grouped together. Top level projects have a Project Management Committee (PMC) that votes on its decisions including accepting new PMC members and new subprojects |
| Archived | Project has been recognized as dead, and has been archived as it’s no longer a going concern |
2.2 Project State Transitions
The valid transitions (and their associated reviews) are:
| From State | To State | Review |
| <null> | Proposal | |
| Proposal | Inclubation | Creation Review |
| Incubation | Mature | Graduation Review |
| Mature | Core | Promotion Review |
| {Mature, Core} | Top Level | Elevation Review |
| {Proposal, Incubation, Mature, Core, Top Level} | Archived | Termination Review |
2.3 Reviews
- For each review, there will be a publicly visible wiki/web template filled out containing the relevant review information.
- The review document must be posted and announced for public comment for at least 2 weeks prior to the date the review is scheduled
- Reviews ideally should be conducted in a manner that is sensitive to the global nature of the community (i.e., the geography and time zone dispersion).
- Reviews may in some circumstances be combined (for example a creation and graduation review for a project seeking to come into OpenDaylight that is already mature in its previous venue). Note, if reviews are combined, the review document need only go through a single 2 week review period (ie, if project combines graduation and promotion review, it need not wait 4 weeks, just the 2).
2.3.1 Creation Review
- Proposal Posted for 2 weeks:
- Name (trademark) OK
- Project Contact Name and Email
- Repository Name, should be:
- Lower Case
- Short
- Suitable to use as a Java/C identifier like a package name
- Description Complete
- Scope well defined
- Resources Committed (developers committed to working)
- Committers Identified
- Vendor Neutral
- Meets Board Policy (including IPR)
- Review by TSC and Approval
2.3.2 Graduation Review
- Graduation Proposal Posted for 2 weeks:
- Working code base
- Active Community
- History of Releases (using Mature Release Process)
- Destination Top Level Project Specified
- Acceptance of conditions of proposed TLP
- Committers vote on seeking graduation
- Accepted by vote of destination
- Review by TSC and Approval
2.3.3 Promotion Review
- Promotion Proposal Posted for 2 weeks:
- Statement of centrality of role
- Diverse community of committers and contributors
- Project Lead Name & Email
- Committers vote on seeking promotion
- Review by TSC and Approval
2.3.4 Elevation Review
1. Elevation Proposal Posted for 2 weeks:
- Scope of acceptable subprojects
- Statement of requirements placed on subprojects, both mature and incubator
- Identified at least two proposed subproject
- Committers vote on seeking elevation
- Review by TSC and Approval
2.3.5 Termination Review
- Termination Proposal Posted for 2 weeks:
- States reason for project termination being sought
- Calls out impact on other project, users, communities, and how those will be mitigated
- Indicates where the project would be archived
- Can be initiated by vote of project committers
- Can be initiated by TSC or PMC of containing project if there are either no remaining committers for the project or there have been no commits to the SCM in 18 months
The basic idea behind the mature release process is to define the most straight forward way to insure that projects can coordinate with each other. The idea is to have simple, clear, public declarations of what they are going to do and when, and that they’ve done it. Towards that end a ‘Mature’ (or Core) project
should have a Release Plan published at the beginning of it’s release cycle by its committers, and a Release Review just prior to the project release.
These should contain sections roughly as follows:
Release Plan:
- Introduction
- Release Deliverables
- Release Milestones
- Expected Dependencies on other Projects
- Compatibility with Previous Releases
- Themes and Priorities
- Other
Release Review:
- Features
- Non-Code Aspects (user docs, examples, tutorials, articles)
- Architectural Issues
- Security Issues
- Quality Assurance (test coverage, etc)
- End-of-life (API/Features EOLed in Release)
- Bugzilla (summary of bug situation)
- Standards (summary of standard compliance)
- Schedule (initial schedule and changes over the release cycle)
Both the Release Plan and Release review document are intended to be relatively short, simple, posted publicly on the wiki documents to assist projects in coordinating among themselves, and the general world in gaining visibility.
We have a clearly articulated need to have a Simultaneous Release Cycle to allow us to release a unified stack that works together as a coherent whole from many projects.
Since the Simultaneous Release is clearly a function of coordination among projects, and the function of the TSC is to facilitate cross project collaboration it should originate in the TSC. The TSC should post a Release Plan detailing:
Simultaneous Release Plan:
- Introduction
- Requirements for Participation
- The scheduling, practice, and quality (but not technical content) requirements for a project to participate. In practice these requirements are expected to build upon the ‘Mature’ project standards.
- Milestones & Release Candidates
- Dates and requirements for milestones and release candidates
- This should include by which Milestone a Project must opt in to join
- This should include a concept of ‘offset’ (explained below)
- This should include by which Milestone freezes of various sorts (for example API freeze) need to happen
- Participating Projects
- Projects which have opted in to the simultaneous release
- Communication Channels
Offsets:
Because it is anticipated that we will have a tree of dependencies among projects, and because it is not sensible to require a project to meet a milestone on the same day as it’s dependency, each project within the release should have an ‘offset’.
A project with offset 0 does not depend directly on other projects. A project with offset 1 depends on projects with offset 0. A project with offset 2 depends on projects with offset 0 and 1, and so forth.
When specifying dates of milestone releases, the Simultaneous Release plan must also specify by how many days each offset comes after the milestone date.
In this way, for example, offset 1 project(s) would get a few days to perform integration testing with the actual milestone release of offset 0 before they
have to release the milestone (and likewise with offset 2 etc.), as it is the responsibility of each project to do integration testing with the projects upon which it depends, including regression testing and so on. Likewise which Milestones API freezes have to occur may also be similarly staggered.
It is expected that different projects will have somewhat differing needs. Ultimately then, projects should set standards for their own code flow by vote of their committers. However, that control needs to be subject to some broader concerns, including:
- Ability of the code flow to support policies of the board
- Possible Example:
i. IPR Policy
- Ability of the code flow to support what the TSC deems to be minimal standards
- Possible Examples:
i. Each project must have an authoritative SCM
ii. Only committers may commit directly to the authoritative SCM
iii. Things necessary to implement board policy
- Ability of the code flow to adhere to standards set for a simultaneous release that the project has chosen to join.
- Possible Examples:
i. Require project to publish artifacts
- Ability of the code flow to adhere to standards set by the top level project it choose to join.
- Possible Examples:
i. Require continuous integration
At the time of the formation of the OpenDaylight Project, there are expected to be several initial projects contributed. These initial projects will come in at various levels of maturity. In order to sort these projects into the most appropriate Project Lifecycle state in a way that is clear, consistent, and fair:
- The TSC will choose a bootstrap-request deadline. This deadline shall not be earlier than one month after OpenDaylight launch, nor shall it be later than six months after launch. Given that OpenDaylight launch occurred on April 8, 2013, the range of possible deadlines extends from May 8, 2013 to October 8, 2013. (The TSC selected a 3-month deadline, which maps to July 8, 2013.)
- At any time prior to the bootstrap-request deadline, a project may request entry into bootstrap state. Please note that projects may alternatively elect to follow the steady-state Project Lifecycle by creating a proposal for Incubation. Bootstrap state is not a requirement, but is instead an additional option that is available prior to the bootstrap-request deadline.
- At its first meeting after receiving a bootstrap request, the TSC will decide whether or not the project should be permitted to enter bootstrap state.
- A project in bootstrap state may petition to exit bootstrap state. This petition will preferably request entry into a given Project Lifecycle state, but it may also elect to leave choice of the Project Lifecycle state to the TSC’s discretion.
- At the first meeting following a bootstrap-exit petition, the TSC will make a decision on the petition. This meeting will preferable include representatives of the project. However, these representatives do not have a vote unless they are already TSC members. The disposition of the petition can take one of two forms:
- Leave the project in bootstrap state, or
- Select the proper Project Lifecycle state for the project based on the steady-state Project Lifecycle criteria.
- The project has one week following the TSC’s decision to either accept that decision or to elect to remain in bootstrap state.
- After a given project enters a non-bootstrap state, that project follows the steady state Project Lifecycle.
7. Intra Project Decision Making
For project internal decisions where no consensus can be reached, simple majority vote by Committers via +1 voting should be used. The point of record for such votes is the -dev mailing list for the project. Note that “+1” voting is a mechanism whereby a Committer can indicate agreement with “+1”, indifference with “0”, and desagrreement with “-1”.