*************** Managed Release *************** Managed Release Summary ======================= The Managed Release Process will facilitate timely, stable OpenDaylight releases by allowing the release team to focus on closely managing a small set of core OpenDaylight projects while not imposing undue requirements on projects that prefer more autonomy. Managed Release Goals ===================== Reduce Overhead on Release Team ------------------------------- The Managed Release Model will allow the release team to focus their efforts on a smaller set of more stable, more responsive projects. Reduce Overhead on Projects --------------------------- The Managed Release Model will reduce the overhead both on projects taking part in the Managed Release and Unmanaged Projects. Managed Projects will have fewer, smaller checkpoints consisting of only information that is maximally helpful for driving the release process. Much of the information collected at checkpoints will be automatically scraped, requiring minimal to no effort from projects. Additionally, Managed Release projects should have a more stable development environment, as the projects that can break the jobs they depend on will be a smaller set, more stable and more responsive. Projects that are Unmanaged will have less overhead and reporting. They will be free to develop in their own way, providing their artifacts to include in the final release or choosing to release on their own schedule. They will not be required to submit any checkpoints and will not be expected to work closely with the rest of the OpenDaylight community to resolve breakages. Enable Timely Releases ---------------------- The Managed Release Process will reduce the set of projects that must simultaneously become stable at release time. The release and test teams will be able to focus on orchestrating a quality release for a smaller set of more stable, more responsive projects. The release team will also have greater latitude to step in and help projects that are required for dependency reasons but may not have a large set of active contributors. Managed Projects ================ Managed Projects Summary ======================== Managed Projects are either required by most applications for dependency reasons or are mature, stable, responsive projects that are consistently able to take part in releases without jeopardizing them. Managed Projects will receive additional support from the test and release teams to further their stability and make sure OpenDaylight releases go out on-time. To enable this extra support, Managed Projects will be given less autonomy than OpenDaylight projects have historically been granted. Managed Projects for Dependency Reasons --------------------------------------- Some projects are required by almost all other OpenDaylight projects. These projects must be in the Managed Release for it to support almost every OpenDaylight use case. Such projects will not have a choice about being in the Managed Release, the TSC will decide they are critical to the OpenDaylight platform and include them. They may not always meet the requirements that would normally be imposed on projects that wish to join the Managed Release. Since they cannot be kicked out of the release, the TSC, test and release teams will do their best to help them meet the Managed Release Requirements. This may involve giving Linux Foundation staff temporary committer rights to merge patches on behalf of unresponsive projects, or appointing committers if projects continue to remain unresponsive. The TSC will strive to work with projects and member companies to proactively keep projects healthy and find active contributors who can become committers in the normal way without the need to appoint them in times of crisis. Managed Release Integrated Projects ----------------------------------- Some Managed Projects may decide to release on their own, not as a part of the Simultaneous Release with Snapshot Integrated Projects. Such Release Integrated projects will still be subject to Managed Release Requirements, but will need to follow a different release process. For implementation reasons, the projects that are able to release independently must depend only on other projects that release independently. Therefore the Release Integrated Projects will form a tree starting from odlparent. Currently odlparent and yangtools are the only Release Integrated Projects, but others may join them in the future. Requirements for Managed Projects --------------------------------- Healthy Community +++++++++++++++++ Managed Projects should strive to have a healthy community. Responsiveness ############## Managed Projects should be responsive over email, IRC, Gerrit, Jira and in regular meetings. All committers should be subscribed to their project's mailing list and the release mailing list. For the following particularly time-sensitive events, an appropriate response is expected within two business days. * RC or SR candidate feedback. * Major disruptions to other projects where a Jira weather item was not present and the pending breakage was not reported to the release mailing list. If anyone feels that a Managed Project is not responsive, a grievance process is in place to clearly handle the situation and keep a record for future consideration by the TSC. Active Committers ################# Managed Projects should have sufficient active committers to review contributions in a timely manner, support potential contributors, keep CSIT healthy and generally effectively drive the project. If a project that the TSC deems is critical to the Managed Release is shown to not have sufficient active committers the TSC may step in and appoint additional committers. Projects that can be dropped from the Managed Release will be dropped instead of having additional committers appointed. Managed Projects should regularly prune their committer list to remove inactive committers, following the `Committer Removal Process`_. TSC Attendance ############## Managed Projects are required to send a representative to attend TSC meetings. To facilitate quickly acting on problems identified during TSC meetings, representatives must be a committer to the project they are representing. A single person can represent any number of projects. Representatives will make the following entry into the meeting minutes to record their presence: #project TSC minutes will be scraped per-release to gather attendance statistics. If a project does not provide a representative for at least half of TSC meetings a grievance will be filed for future consideration. Checkpoints Submitted On-Time +++++++++++++++++++++++++++++ Managed Projects must submit information required for checkpoints on-time. Submissions must be correct and adequate, as judged by the release team and the TSC. Inadequate or missing submissions will result in a grievance. Jobs Required for Managed Projects Running ++++++++++++++++++++++++++++++++++++++++++ Managed Projects are required to have the following jobs running and healthy. * Distribution check job (voting) * Validate autorelease job (voting) * Merge job (non-voting) * Sonar job (non-voting) * CLM job (non-voting) Depend only on Managed Projects +++++++++++++++++++++++++++++++ Managed Projects should only depend on other Managed Projects. If a project wants to be Managed but depends on Unmanaged Projects, they should work with their dependencies to become Managed at the same time or drop any Unmanaged dependencies. Documentation +++++++++++++ Managed Projects are required to produce a user guide, developer guide and release notes for each release. CLM +++ Managed Projects are required to handle CLM (Component Lifecycle Management) violations in a timely manner. Managed Release Process ----------------------- Managed Release Checkpoints +++++++++++++++++++++++++++ Checkpoints are designed to be mostly automated, to be maximally effective at driving the release process and to impose as little overhead on projects as possible. There will be an initial checkpoint two weeks after the start of the release, a midway checkpoints one month before code freeze and a final checkpoint at code freeze. Initial Checkpoint ################## An initial checkpoint will be collected two weeks after the start of each release. The release team will review the information collected and report it to the TSC at the next TSC meeting. Projects will need to create the following artifacts: * High-level, human-readable description of what the project plans to do in this release. This should be submitted as a Jira **Project Plan** issue against the TSC project. * Select your project in the **ODL Project** field * Select the release version in the **ODL Release** field * Select the appropriate value in the **ODL Participation** field: ``SNAPSHOT_Integrated (Managed)`` or ``RELEASE_Integrated (Managed)`` * Select the value ``Initial`` in the **ODL Checkpoint** field * In the **Summary** field, put something like: ``Project-X Fluorine Release Plan`` * In the **Description** field, fill in the details of your plan: .. code-block:: none This should list a high-level, human-readable summary of what a project plans to do in a release. It should cover the project's planned major accomplishments during the release, such as features, bugfixes, scale, stability or longevity improvements, additional test coverage, better documentation or other improvements. It may cover challenges the project is facing and needs help with from other projects, the TSC or the LFN umbrella. It should be written in a way that makes it amenable to use for external communication, such as marketing to users or a report to other LFN projects or the LFN Board. * If a project is transitioning from Unmanaged to Managed or applying for the first time into a Managed release, raise a Jira **Project Plan** issue against the TSC project highlighting the request. * Select your project in the **ODL Project** field * Select the release version in the **ODL Release** field * Select the ``NOT_Integrated (Unmanaged)`` value in the **ODL Participation** field * Select the appropriate value in the **ODL New Participation** field: ``SNAPSHOT_Integrated (Managed)`` or ``RELEASE_Integrated (Managed)`` * In the **Summary** field, put something like: ``Project-X joining/moving to Managed Release for Fluorine`` * In the **Description** field, fill in the details using the template below: .. code-block:: none Summary This is an example of a request for a project to move from Unmanaged to Managed. It should be submitted no later than the start of the release. The request should make it clear that the requesting project meets all of the Managed Release Requirements. Healthy Community The request should make it clear that the requesting project has a healthy community. The request may also highlight a history of having a healthy community. Responsiveness The request should make it clear that the requesting project is responsive over email, IRC, Jira and in regular meetings. All committers should be subscribed to the project's mailing list and the release mailing list. The request may also highlight a history of responsiveness. Active Committers The request should make it clear that the requesting project has a sufficient number of active committers to review contributions in a timely manner, support potential contributors, keep CSIT healthy and generally effectively drive the project. The requesting project should also make it clear that they have pruned any inactive committers. The request may also highlight a history of having sufficient active committers and few inactive committers. TSC Attendance The request should acknowledge that the requesting project is required to send a committer to represent the project to at least 50% of TSC meetings. The request may also highlight a history of sending representatives to attend TSC meetings. Checkpoints Submitted On-Time The request should acknowledge that the requesting project is required to submit checkpoints on time. The request may also highlight a history of providing deliverables on time. Jobs Required for Managed Projects Running The request should show that the requesting project has the required jobs for Managed Projects running and healthy. Links should be provided. Depend only on Managed Projects The request should show that the requesting project only depends on Managed Projects. Documentation The request should acknowledge that the requesting project is required to produce a user guide, developer guide and release notes for each release. The request may also highlight a history of providing quality documentation. CLM The request should acknowledge that the requesting project is required to handle Component Lifecycle Violations in a timely manner. The request should show that the project's CLM job is currently healthy. The request may also show that the project has a history of dealing with CLM violations in a timely manner. * If a project is transitioning from Managed to Unmanaged, raise a Jira **Project Plan** issue against the TSC project highlighting the request. * Select your project in the **ODL Project** field * Select the release version in the **ODL Release** field * Select the appropriate value in the **ODL Participation** field: ``SNAPSHOT_Integrated (Managed)`` or ``RELEASE_Integrated (Managed)`` * Select the ``NOT_Integrated (Unmanaged)`` value in the **ODL New Participation** field * In the **Summary** field, put something like: ``Project-X Fluorine Joining/Moving to Unmanged for Fluorine`` * In the **Description** field, fill in the details: .. code-block:: none This is a request for a project to move from Unmanged to Managed. It should be submitted no later than the start of the release. The request does not require any additional information, but it may be helpful for the requesting project to provide some background and their reasoning. * Weather items that may impact other projects should be submitted as Jira issues. For a weather item, raise a Jira **Weather Item** issue against the TSC project highlighting the details. * Select your project in the **ODL Project** field * Select the release version in the **ODL Release** field * For the **ODL Impacted Projects** field, fill in the impacted projects using label values - each label value should correspond to the respective project prefix in Jira, e.g. netvirt is NETVIRT. If all projects are impacted, use the label value ``ALL``. * Fill in the expected date of weather event in the **ODL Expected Date** field * Select the appropriate value for **ODL Checkpoint** (may skip) * In the **Summary** field, summarize the weather event * In the **Description** field, provide the details of the weather event. Provide as much relevant information as possible. The remaining artifacts will be automatically scraped: * Blocker bugs that were raised between the previous code freeze and release. * Grievances raised against the project during the last release. Midway Checkpoint ################# One month before code freeze, a midway checkpoint will be collected. The release team will review the information collected and report it to the TSC at the next TSC meeting. All information for midway checkpoint will be automatically collected. * Open Jira bugs marked as blockers. * Open Jira issues tracking weather items. * Statistics about jobs. * Autorelease failures per-project. * CLM violations. * Grievances raised against the project since the last checkpoint. Since the midway checkpoint is fully automated, the release team may collect this information more frequently, to provide trends over time. Final Checkpoint ################ At 2 weeks after code freeze a final checkpoint will be collected by the release team and presented to the TSC at the next TSC meeting. Projects will need to create the following artifacts: * High-level, human-readable description of what the project did in this release. This should be submitted as a Jira **Project Plan** issue against the TSC project. This will be reused for external communication/marketing for the release. * Select your project in the **ODL Project** field * Select the release version in the **ODL Release** field * Select the appropriate value in the **ODL Participation** field: ``SNAPSHOT_Integrated (Managed)`` or ``RELEASE_Integrated (Managed)`` * Select the value ``Final`` in the **ODL Checkpoint** field * In the **Summary** field, put something like: ``Project-X Fluorine Release details`` * In the **Description** field, fill in the details of your accomplishments: .. code-block:: none This should be a high-level, human-readable summary of what a project did during a release. It should cover the project's major accomplishments, such as features, bugfixes, scale, stability or longevity improvements, additional test coverage, better documentation or other improvements. It may cover challenges the project has faced and needs help in the future from other projects, the TSC or the LFN umbrella. It should be written in a way that makes it amenable to use for external communication, such as marketing to users or a report to other LFN projects or the LFN Board. * In the **ODL Gerrit Patch** field, fill in the Gerrit patch URL to your project release notes * Release notes, user guide, developer guide submitted to the docs project. The remaining artifacts will be automatically scraped: * Open Jira bugs marked as blockers. * Open Jira issues tracking weather items. * Statistics about jobs. * Autorelease failures per-project. * Statistics about patches. * Number of patches submitted during the release. * Number of patches merged during the release. * Number of reviews per-reviewer. * Grievances raised against the project since the start of the release. Managed Release Integrated Release Process ------------------------------------------ Managed Projects that release independently (Release Integrated Projects), not as a part of the Simultaneous Release with Snapshot Integrated Projects, will need to follow a different release process. Managed Release Integrated (MRI) Projects will provide the releases they want the Managed Snapshot Integrated (MSI) Projects to consume no later than two weeks after the start of the Managed Release. The TSC will decide by a majority vote whether to bump MSI versions to consume the new MRI releases. This should happen as early in the release as possible to get integration woes out of the way and allow projects to focus on developing against a stable base. If the TSC decide to consume the proposed MRI releases, all MSI Projects are required to bump to the new versions within a two day window. If some projects fail to merge version bump patches in time, the TSC will instruct Linux Foundation staff to temporarily wield committer rights and merge version bump patches. The TSC vote at any time to back out of a version bump if the new releases are found to be unsuitable. MRI Projects are expected to provide bugfixes via minor or patch version updates during the release, but should strive to not expect MSI Projects to consume another major version update during the release. MRI Projects are free to follow their own release cadence as they develop new features during the Managed Release. They need only have a stable version ready for the MSI Projects to consume by the next integration point. Managed Release Integrated Checkpoints ++++++++++++++++++++++++++++++++++++++ The MRI Projects will follow similar checkpoints as the MSI Projects, but the timing will be different. At the time MRI Projects provide the releases they wish MSI Projects to consume for the next release, they will also provide their final checkpoints. Their midway checkpoints will be scraped one month before the deadline for them to deliver their artifacts to the MSI Projects. Their initial checkpoints will be due no later two weeks following the deadline for their delivery of artifacts to the MSI Projects. Their initial checkpoints will cover everything they expect to do in the next Managed Release, which may encompass any number of major version bumps for the MRI Projects. Moving a Project from Unmanaged to Managed ------------------------------------------ Unmanaged Projects can request to become Managed by submitting a **Project_Plan** issue to the TSC project in Jira. See details as described under the `Initial Checkpoint`_ section above. Requests should be submitted before the start of a release. The requesting project should make it clear that they meet the Managed Release Project Requirements. The TSC will evaluate requests to become Managed and inform projects of the result and the TSC's reasoning no later than the start of the release or one week after the request was submitted, whichever comes last. For the first release, the TSC will bootstrap the Managed Release with projects that are critical to the OpenDaylight platform. Other projects will need to follow the normal application process defined above. The following projects are deemed critical to the OpenDaylight platform: * aaa * controller * infrautils * mdsal * netconf * odlparent * yangtools Unmanaged Projects ================== Requirements for Unmanaged Projects ----------------------------------- Unmanaged Project requirements are designed to be as low-overhead as possible while still allowing for participation in the final release. If Unmanaged Projects do not want to participate in the final release and instead provide their artifacts to their consumers through another channel, there are no requirements. SNAPSHOT Versions by Release ++++++++++++++++++++++++++++ Unmanaged Projects can consume whichever version of their upstream dependencies they want during most of the release cycle, but if they want to be included in the final release distribution they must bump their versions to SNAPSHOT no later than one week before code freeze. Jobs Required for Unmanaged Projects Running ++++++++++++++++++++++++++++++++++++++++++++ Unmanaged Projects that wish to take part in the final release must enable the validate-autorelease job. Unmanaged Projects can release artifacts at any time using the release job. To take part in the final release, Unmanaged Projects will need to run the release job with the version of the final distribution no later than one week before code freeze. Added to Final Distribution POM +++++++++++++++++++++++++++++++ In order to be included in the final distribution, Unmanaged Projects must submit a patch to include themselves in the final distribution pom.xml file no later than one week before code freeze. Projects should only be added to the final distribution pom.xml after they have published artifacts with the release job to avoid breaking the build. Unmanaged Release Process ------------------------- Unmanaged Projects are free to follow their own processes. To have their artifacts included in the final distribution, they need only follow the Requirements for Unmanaged Projects above by the deadlines. Note that Unmanaged Projects will not have any leeway for missing deadlines. If projects are not in the final distribution by one week before code freeze their artifacts will not be included in the final release, but they may still publish artifacts and help their consumers install them out-of-band. Checkpoints +++++++++++ There are no checkpoints for Unmanaged Projects. Moving a Project from Managed to Unmanaged ------------------------------------------ Managed Projects that are not required for dependency reasons can submit a **Project_Plan** issue to be Unmanaged to the TSC project in Jira. See details in the `Initial Checkpoint`_ section above. Requests should be submitted before the start of a release. Requests will be evaluated by the TSC. The TSC may withdraw a project from the Managed Release at any time. Installing Features from Unmanaged Projects ------------------------------------------- Unmanaged Projects will have their artifacts included in the final release if they are available on-time, but they will not be available to be installed until the user does a repo:add. To install an Unmanaged Project feature, find the feature description in the system directory. For example, NetVirt's main feature: system/org/opendaylight/netvirt/odl-netvirt-openstack/0.6.0-SNAPSHOT/ Then use the Karaf shell to repo:add the feature: feature:repo-add mvn:org.opendaylight.netvirt/odl-netvirt-openstack/0.6.0 -SNAPSHOT/xml/features Grievances ========== For requirements that are difficult to automatically ascertain if a Managed Project is following or not, there should be a clear reporting process. Grievance reports should be filed against the TSC project in Jira. Very urgent grievances can additionally be brought to the TSC's attention via the TSC's mailing list. Process for Reporting Unresponsive Projects ------------------------------------------- If a Managed Project does not meet the `Responsiveness`_ Requirements, a **Grievance** issue should be filed against the TSC project in Jira. Unresponsive project reports should include (at least): * Select the project being reported in the **ODL_Project** field * Select the release version in the **ODL_Release** field * In the **Summary** field, put something like: ``Grievance against Project-X`` * In the **Description** field, fill in the details: .. code-block:: none Document the details that show ExampleProject was slow to review a change. The report should include as much relevant information as possible, including a description of the situation, relevant Gerrit change IDs and relevant public email list threads. * In the **ODL_Gerrit_Patch**, put in a URL to a Gerrit patch, if applicable Release Schedule ================ The start date for odd release is September 7 and the start date for even release is March 7. .. list-table:: :widths: 20 20 20 40 :header-rows: 1 :stub-columns: 1 * - **Milestone** - **Time** - **Fluorine** - **Description** * - Release Start - Start Date - 2018-03-07 - Declare Intention: Submit **Project_Plan** Jira item in TSC project * - Initial Checkpoint - Start Date + 2 weeks - 2018-03-22 - Initial Checkpoint. All Managed Projects must have completed **Project_Plan** Jira items in TSC project. * - Release Integrated Deadline - Initial Checkpoint + 2 weeks - 2018-04-07 - Deadline for Release Integrated Projects (currently ODLPARENT and YANGTOOLS) to provide the desired version deliverables for downstream Snapshot Integrated Projects to consume. * - Version Bump - Release Integrated Deadline + 1 day - 2018-04-08 - Prepare version bump patches and merge them in (RelEng team). Spend the next 2 weeks to get green build for all MSI Projects and a healthy distribution. * - Version Bump Checkpoint - Release Integrated Deadline + 2 weeks - 2018-04-21 - Check status of MSI Projects to see if we have green builds and a healthy distribution. Revert the MRI deliverables if deemed necessary. * - CSIT Checkpoint - Version Bump Checkpoint + 2 weeks - 2018-05-07 - All Managed Release CSIT should be in good shape - get all MSI Projects' CSIT results as they were before the version bump. This is the final opportunity to revert the MRI deliverables if deemed necessary. * - Middle Checkpoint - CSIT Checkpoint + 8 weeks - 2018-07-05 - Checkpoint for status of Managed Projects - especially Snapshot Integrated Projects. * - Code Freeze - Middle Checkpoint + 4 weeks - 2018-08-07 - Code freeze for all Managed Projects - cut and lock release branch. Only allow blocker bugfixes in release branch. * - Final Checkpoint - TSC meeting 2 weeks after Code Freeze - 2018-08-23 - Final Checkpoint for all Managed Projects. * - Formal Release - 6 months after Start Date - 2018-09-07 - Formal release * - Service Release 1 - 1 month after Formal Release - 2018-10-07 - Service Release 1 (SR1) * - Service Release 2 - 2 months after SR1 - 2018-12-07 - Service Release 2 (SR2) * - Service Release 3 - 2 months after SR2 - 2019-02-07 - Service Release 3 (SR3) * - Service Release 4 - 3 months after SR3 - 2019-05-07 - Service Release 4 (SR4) - final service release * - Release End of Life - 4 months after SR4 - 2019-09-07 - End of Life - coincides with the Formal Release of the current release+2 versions and the start of the current release+3 versions Vocabulary Reference ==================== * Managed Release Process: The release process described in this document. * Managed Project: A project taking part in the Managed Release Process. * Unmanaged Project: A project not taking part in the Managed Release Process. * Simultaneous Release: Event wherein all Snapshot Integrated Project versions are rewriten to release versions and release artifacts are produced. * Snapshot Integrated Project: Project that integrates with OpenDaylight projects using snapshot version numbers. These projects release together in the Simultaneous Release. * Release Integrated Project: Project that releases independently of the Simultaneous Release. These projects are consumed by Snapshot Integrated Projects based on release version numbers, not snapshot versions. .. _Committer Removal Process: https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process