OVSDB Milestone Final readout
[docs.git] / docs / release-process / managed-release.rst
1 ***************
2 Managed Release
3 ***************
4
5 Managed Release Summary
6 =======================
7
8 The Managed Release Process will facilitate timely, stable OpenDaylight
9 releases by allowing the release team to focus on closely managing a small set
10 of core OpenDaylight projects while not imposing undue requirements on projects
11 that prefer more autonomy.
12
13 Managed Release Goals
14 =====================
15
16 Reduce Overhead on Release Team
17 -------------------------------
18
19 The Managed Release Model will allow the release team to focus their efforts
20 on a smaller set of more stable, more responsive projects.
21
22 Reduce Overhead on Projects
23 ---------------------------
24
25 The Managed Release Model will reduce the overhead both on projects taking
26 part in the Managed Release and Unmanaged Projects.
27
28 Managed Projects will have fewer, smaller checkpoints consisting of only
29 information that is maximally helpful for driving the release process. Much of
30 the information collected at checkpoints will be automatically scraped,
31 requiring minimal to no effort from projects. Additionally, Managed Release
32 projects should have a more stable development environment, as the projects
33 that can break the jobs they depend on will be a smaller set, more stable and
34 more responsive.
35
36 Projects that are Unmanaged will have less overhead and reporting. They will
37 be free to develop in their own way, providing their artifacts to include in
38 the final release or choosing to release on their own schedule. They will not
39 be required to submit any checkpoints and will not be expected to work closely
40 with the rest of the OpenDaylight community to resolve breakages.
41
42 Enable Timely Releases
43 ----------------------
44
45 The Managed Release Process will reduce the set of projects that must
46 simultaneously become stable at release time. The release and test teams will
47 be able to focus on orchestrating a quality release for a smaller set of more
48 stable, more responsive projects. The release team will also have greater
49 latitude to step in and help projects that are required for dependency reasons
50 but may not have a large set of active contributors.
51
52 Managed Projects
53 ================
54
55 Managed Projects Summary
56 ========================
57
58 Managed Projects are either required by most applications for dependency
59 reasons or are mature, stable, responsive projects that are consistently able
60 to take part in releases without jeopardizing them. Managed Projects will
61 receive additional support from the test and release teams to further their
62 stability and make sure OpenDaylight releases go out on-time. To enable this
63 extra support, Managed Projects will be given less autonomy than OpenDaylight
64 projects have historically been granted.
65
66 Managed Projects for Dependency Reasons
67 ---------------------------------------
68
69 Some projects are required by almost all other OpenDaylight projects. These
70 projects must be in the Managed Release for it to support almost every
71 OpenDaylight use case. Such projects will not have a choice about being in the
72 Managed Release, the TSC will decide they are critical to the OpenDaylight
73 platform and include them. They may not always meet the requirements that
74 would normally be imposed on projects that wish to join the Managed Release.
75 Since they cannot be kicked out of the release, the TSC, test and release teams
76 will do their best to help them meet the Managed Release Requirements. This
77 may involve giving Linux Foundation staff temporary committer rights to merge
78 patches on behalf of unresponsive projects, or appointing committers if
79 projects continue to remain unresponsive. The TSC will strive to work with
80 projects and member companies to proactively keep projects healthy and find
81 active contributors who can become committers in the normal way without the
82 need to appoint them in times of crisis.
83
84 Managed Release Integrated Projects
85 -----------------------------------
86
87 Some Managed Projects may decide to release on their own, not as a part of the
88 Simultaneous Release with Snapshot Integrated Projects. Such Release Integrated
89 projects will still be subject to Managed Release Requirements, but will need
90 to follow a different release process.
91
92 For implementation reasons, the projects that are able to release independently
93 must depend only on other projects that release independently. Therefore the
94 Release Integrated Projects will form a tree starting from odlparent. Currently
95 odlparent and yangtools are the only Release Integrated Projects, but others
96 may join them in the future.
97
98 Requirements for Managed Projects
99 ---------------------------------
100
101 Healthy Community
102 +++++++++++++++++
103
104 Managed Projects should strive to have a healthy community.
105
106 Responsiveness
107 ##############
108
109 Managed Projects should be responsive over email, IRC, Gerrit, Jira and in
110 regular meetings.
111
112 All committers should be subscribed to their project's mailing list and the
113 release mailing list.
114
115 For the following particularly time-sensitive events, an appropriate response
116 is expected within two business days.
117
118 * RC or SR candidate feedback.
119 * Major disruptions to other projects where a Jira weather item was not present
120   and the pending breakage was not reported to the release mailing list.
121
122 If anyone feels that a Managed Project is not responsive, a grievance process
123 is in place to clearly handle the situation and keep a record for future
124 consideration by the TSC.
125
126 Active Committers
127 #################
128
129 Managed Projects should have sufficient active committers to review
130 contributions in a timely manner, support potential contributors, keep CSIT
131 healthy and generally effectively drive the project.
132
133 If a project that the TSC deems is critical to the Managed Release is shown to
134 not have sufficient active committers the TSC may step in and appoint
135 additional committers. Projects that can be dropped from the Managed Release
136 will be dropped instead of having additional committers appointed.
137
138 Managed Projects should regularly prune their committer list to remove
139 inactive committers, following the `Committer Removal Process`_.
140
141 TSC Attendance
142 ##############
143
144 Managed Projects are required to send a representative to attend TSC meetings.
145
146 To facilitate quickly acting on problems identified during TSC meetings,
147 representatives must be a committer to the project they are representing. A
148 single person can represent any number of projects.
149
150 Representatives will make the following entry into the meeting minutes to
151 record their presence:
152
153 #project <project ID>
154
155 TSC minutes will be scraped per-release to gather attendance statistics. If a
156 project does not provide a representative for at least half of TSC meetings a
157 grievance will be filed for future consideration.
158
159 Checkpoints Submitted On-Time
160 +++++++++++++++++++++++++++++
161
162 Managed Projects must submit information required for checkpoints on-time.
163 Submissions must be correct and adequate, as judged by the release team and
164 the TSC. Inadequate or missing submissions will result in a grievance.
165
166 Jobs Required for Managed Projects Running
167 ++++++++++++++++++++++++++++++++++++++++++
168
169 Managed Projects are required to have the following jobs running and healthy.
170
171 * Distribution check job (voting)
172 * Validate autorelease job (voting)
173 * Merge job (non-voting)
174 * Sonar job (non-voting)
175 * CLM job (non-voting)
176
177 Depend only on Managed Projects
178 +++++++++++++++++++++++++++++++
179
180 Managed Projects should only depend on other Managed Projects.
181
182 If a project wants to be Managed but depends on Unmanaged Projects, they
183 should work with their dependencies to become Managed at the same time or
184 drop any Unmanaged dependencies.
185
186 Documentation
187 +++++++++++++
188
189 Managed Projects are required to produce a user guide, developer guide and
190 release notes for each release.
191
192 CLM
193 +++
194
195 Managed Projects are required to handle CLM (Component Lifecycle Management)
196 violations in a timely manner.
197
198 Managed Release Process
199 -----------------------
200
201 Managed Release Checkpoints
202 +++++++++++++++++++++++++++
203
204 Checkpoints are designed to be mostly automated, to be maximally effective at
205 driving the release process and to impose as little overhead on projects as
206 possible.
207
208 There will be an initial checkpoint two weeks after the start of the release,
209 a midway checkpoints one month before RC0 and a final checkpoint at RC0.
210
211 Initial Checkpoint
212 ##################
213
214 An initial checkpoint will be collected two weeks after the start of each
215 release. The release team will review the information collected and report
216 it to the TSC at the next TSC meeting.
217
218 Projects will need to create the following artifacts:
219
220 * High-level, human-readable description of what the project plans to do in this
221   release. This should be submitted as a Jira **Project Plan** issue against the
222   TSC project.
223
224   * Select your project in the **ODL Project** field
225
226   * Select the release version in the **ODL Release** field
227
228   * Select the appropriate value in the **ODL Participation** field:
229     ``SNAPSHOT_Integrated (Managed)`` or ``RELEASE_Integrated (Managed)``
230
231   * Select the value ``Initial`` in the **ODL Checkpoint** field
232
233   * In the **Summary** field, put something like:
234     ``Project-X Fluorine Release Plan``
235
236   * In the **Description** field, fill in the details of your plan:
237
238     .. code-block:: none
239
240        This should list a high-level, human-readable summary of what a project
241        plans to do in a release. It should cover the project's planned major
242        accomplishments during the release, such as features, bugfixes, scale,
243        stability or longevity improvements, additional test coverage, better
244        documentation or other improvements. It may cover challenges the project
245        is facing and needs help with from other projects, the TSC or the LFN
246        umbrella. It should be written in a way that makes it amenable to use
247        for external communication, such as marketing to users or a report to
248        other LFN projects or the LFN Board.
249
250 * If a project is transitioning from Unmanaged to Managed or applying for
251   the first time into a Managed release, raise a Jira **Project Plan** issue
252   against the TSC project highlighting the request.
253
254   * Select your project in the **ODL Project** field
255
256   * Select the release version in the **ODL Release** field
257
258   * Select the ``NOT_Integrated (Unmanaged)`` value in the **ODL Participation**
259     field
260
261   * Select the appropriate value in the **ODL New Participation** field:
262     ``SNAPSHOT_Integrated (Managed)`` or ``RELEASE_Integrated (Managed)``
263
264   * In the **Summary** field, put something like:
265     ``Project-X joining/moving to Managed Release for Fluorine``
266
267   * In the **Description** field, fill in the details using the template
268     below:
269
270     .. code-block:: none
271
272        Summary
273        This is an example of a request for a project to move from Unmanaged to
274        Managed. It should be submitted no later than the start of the release.
275        The request should make it clear that the requesting project meets all
276        of the Managed Release Requirements.
277
278        Healthy Community
279        The request should make it clear that the requesting project has a
280        healthy community. The request may also highlight a history of having a
281        healthy community.
282
283        Responsiveness
284        The request should make it clear that the requesting project is
285        responsive over email, IRC, Jira and in regular meetings. All committers
286        should be subscribed to the project's mailing list and the release
287        mailing list. The request may also highlight a history of
288        responsiveness.
289
290        Active Committers
291        The request should make it clear that the requesting project has a
292        sufficient number of active committers to review contributions in a
293        timely manner, support potential contributors, keep CSIT healthy and
294        generally effectively drive the project. The requesting project should
295        also make it clear that they have pruned any inactive committers. The
296        request may also highlight a history of having sufficient active
297        committers and few inactive committers.
298
299        TSC Attendance
300        The request should acknowledge that the requesting project is required
301        to send a committer to represent the project to at least 50% of TSC
302        meetings. The request may also highlight a history of sending
303        representatives to attend TSC meetings.
304
305        Checkpoints Submitted On-Time
306        The request should acknowledge that the requesting project is required
307        to submit checkpoints on time. The request may also highlight a history
308        of providing deliverables on time.
309
310        Jobs Required for Managed Projects Running
311        The request should show that the requesting project has the required
312        jobs for Managed Projects running and healthy. Links should be provided.
313
314        Depend only on Managed Projects
315        The request should show that the requesting project only depends on
316        Managed Projects.
317
318        Documentation
319        The request should acknowledge that the requesting project is required
320        to produce a user guide, developer guide and release notes for each
321        release. The request may also highlight a history of providing quality
322        documentation.
323
324        CLM
325        The request should acknowledge that the requesting project is required
326        to handle Component Lifecycle Violations in a timely manner. The request
327        should show that the project's CLM job is currently healthy. The request
328        may also show that the project has a history of dealing with CLM
329        violations in a timely manner.
330
331 * If a project is transitioning from Managed to Unmanaged, raise a Jira
332   **Project Plan** issue against the TSC project highlighting the request.
333
334   * Select your project in the **ODL Project** field
335
336   * Select the release version in the **ODL Release** field
337
338   * Select the appropriate value in the **ODL Participation** field:
339     ``SNAPSHOT_Integrated (Managed)`` or ``RELEASE_Integrated (Managed)``
340
341   * Select the ``NOT_Integrated (Unmanaged)`` value in the
342     **ODL New Participation** field
343
344   * In the **Summary** field, put something like:
345     ``Project-X Fluorine Joining/Moving to Unmanged for Fluorine``
346
347   * In the **Description** field, fill in the details:
348
349     .. code-block:: none
350
351        This is a request for a project to move from Unmanged to Managed. It
352        should be submitted no later than the start of the release. The request
353        does not require any additional information, but it may be helpful for
354        the requesting project to provide some background and their reasoning.
355
356 * Weather items that may impact other projects should be submitted as Jira
357   issues. For a weather item, raise a Jira **Weather Item** issue against the
358   TSC project highlighting the details.
359
360   * Select your project in the **ODL Project** field
361
362   * Select the release version in the **ODL Release** field
363
364   * For the **ODL Impacted Projects** field, fill in the impacted projects
365     using label values - each label value should correspond to the respective
366     project prefix in Jira, e.g. netvirt is NETVIRT. If all projects are
367     impacted, use the label value ``ALL``.
368
369   * Fill in the expected date of weather event in the **ODL Expected Date**
370     field
371
372   * Select the appropriate value for **ODL Checkpoint** (may skip)
373
374   * In the **Summary** field, summarize the weather event
375
376   * In the **Description** field, provide the details of the weather event.
377     Provide as much relevant information as possible.
378
379 The remaining artifacts will be automatically scraped:
380
381 * Blocker bugs that were raised between the previous RC0 and release.
382 * Grievances raised against the project during the last release.
383
384 Midway Checkpoint
385 #################
386
387 One month before RC0, a midway checkpoint will be collected. The release team
388 will review the information collected and report it to the TSC at the next TSC
389 meeting. All information for midway checkpoint will be automatically collected.
390
391 * Open Jira bugs marked as blockers.
392 * Open Jira issues tracking weather items.
393 * Statistics about jobs.
394   * Autorelease failures per-project.
395   * CLM violations.
396 * Grievances raised against the project since the last checkpoint.
397
398 Since the midway checkpoint is fully automated, the release team may collect
399 this information more frequently, to provide trends over time.
400
401 Final Checkpoint
402 ################
403
404 At 2 weeks after RC0 a final checkpoint will be collected by the release team
405 and presented to the TSC at the next TSC meeting.
406
407 Projects will need to create the following artifacts:
408
409 * High-level, human-readable description of what the project did in this
410   release. This should be submitted as a Jira **Project Plan** issue against
411   the TSC project. This will be reused for external communication/marketing for
412   the release.
413
414   * Select your project in the **ODL Project** field
415
416   * Select the release version in the **ODL Release** field
417
418   * Select the appropriate value in the **ODL Participation** field:
419     ``SNAPSHOT_Integrated (Managed)`` or ``RELEASE_Integrated (Managed)``
420
421   * Select the value ``Final`` in the **ODL Checkpoint** field
422
423   * In the **Summary** field, put something like:
424     ``Project-X Fluorine Release details``
425
426   * In the **Description** field, fill in the details of your accomplishments:
427
428     .. code-block:: none
429
430        This should be a high-level, human-readable summary of what a project
431        did during a release. It should cover the project's major
432        accomplishments, such as features, bugfixes, scale, stability or
433        longevity improvements, additional test coverage, better documentation
434        or other improvements. It may cover challenges the project has faced
435        and needs help in the future from other projects, the TSC or the LFN
436        umbrella. It should be written in a way that makes it amenable to use
437        for external communication, such as marketing to users or a report to
438        other LFN projects or the LFN Board.
439
440   * In the **ODL Gerrit Patch** field, fill in the Gerrit patch URL to your
441     project release notes
442
443 * Release notes, user guide, developer guide submitted to the docs project.
444
445 The remaining artifacts will be automatically scraped:
446
447 * Open Jira bugs marked as blockers.
448 * Open Jira issues tracking weather items.
449 * Statistics about jobs.
450   * Autorelease failures per-project.
451 * Statistics about patches.
452   * Number of patches submitted during the release.
453   * Number of patches merged during the release.
454   * Number of reviews per-reviewer.
455 * Grievances raised against the project since the start of the release.
456
457 Managed Release Integrated Release Process
458 ------------------------------------------
459
460 Managed Projects that release independently (Release Integrated Projects),
461 not as a part of the Simultaneous Release with Snapshot Integrated Projects,
462 will need to follow a different release process.
463
464 Managed Release Integrated (MRI) Projects will provide the releases they want
465 the Managed Snapshot Integrated (MSI) Projects to consume no later than two
466 weeks after the start of the Managed Release. The TSC will decide by a majority
467 vote whether to bump MSI versions to consume the new MRI releases. This should
468 happen as early in the release as possible to get integration woes out of the
469 way and allow projects to focus on developing against a stable base. If the TSC
470 decide to consume the proposed MRI releases, all MSI Projects are required to
471 bump to the new versions within a two day window. If some projects fail to
472 merge version bump patches in time, the TSC will instruct Linux Foundation
473 staff to temporarily wield committer rights and merge version bump patches.
474 The TSC vote at any time to back out of a version bump if the new releases are
475 found to be unsuitable.
476
477 MRI Projects are expected to provide bugfixes via minor or patch version
478 updates during the release, but should strive to not expect MSI Projects to
479 consume another major version update during the release.
480
481 MRI Projects are free to follow their own release cadence as they develop new
482 features during the Managed Release. They need only have a stable version ready
483 for the MSI Projects to consume by the next integration point.
484
485 Managed Release Integrated Checkpoints
486 ++++++++++++++++++++++++++++++++++++++
487
488 The MRI Projects will follow similar checkpoints as the MSI Projects, but the
489 timing will be different. At the time MRI Projects provide the releases they
490 wish MSI Projects to consume for the next release, they will also provide their
491 final checkpoints. Their midway checkpoints will be scraped one month before
492 the deadline for them to deliver their artifacts to the MSI Projects. Their
493 initial checkpoints will be due no later two weeks following the deadline for
494 their delivery of artifacts to the MSI Projects. Their initial checkpoints will
495 cover everything they expect to do in the next Managed Release, which may
496 encompass any number of major version bumps for the MRI Projects.
497
498 Moving a Project from Unmanaged to Managed
499 ------------------------------------------
500
501 Unmanaged Projects can request to become Managed by submitting a
502 **Project_Plan** issue to the TSC project in Jira. See details as described
503 under the `Initial Checkpoint`_ section above. Requests should be submitted
504 before the start of a release. The requesting project should make it clear that
505 they meet the Managed Release Project Requirements.
506
507 The TSC will evaluate requests to become Managed and inform projects of the
508 result and the TSC's reasoning no later than the start of the release or one
509 week after the request was submitted, whichever comes last.
510
511 For the first release, the TSC will bootstrap the Managed Release with projects
512 that are critical to the OpenDaylight platform. Other projects will need to
513 follow the normal application process defined above.
514
515 The following projects are deemed critical to the OpenDaylight platform:
516
517 * aaa
518 * controller
519 * infrautils
520 * mdsal
521 * netconf
522 * odlparent
523 * yangtools
524
525 Unmanaged Projects
526 ==================
527
528 Requirements for Unmanaged Projects
529 -----------------------------------
530
531 Unmanaged Project requirements are designed to be as low-overhead as possible
532 while still allowing for participation in the final release. If Unmanaged
533 Projects do not want to participate in the final release and instead provide
534 their artifacts to their consumers through another channel, there are no
535 requirements.
536
537 SNAPSHOT Versions by Release
538 ++++++++++++++++++++++++++++
539
540 Unmanaged Projects can consume whichever version of their upstream dependencies
541 they want during most of the release cycle, but if they want to be included in
542 the final release distribution they must bump their versions to SNAPSHOT no
543 later than one week before RC0.
544
545 Jobs Required for Unmanaged Projects Running
546 ++++++++++++++++++++++++++++++++++++++++++++
547
548 Unmanaged Projects that wish to take part in the final release must enable the
549 validate-autorelease job. Unmanaged Projects can release artifacts at any time
550 using the release job. To take part in the final release, Unmanaged Projects
551 will need to run the release job with the version of the final distribution no
552 later than one week before RC0.
553
554 Added to Final Distribution POM
555 +++++++++++++++++++++++++++++++
556
557 In order to be included in the final distribution, Unmanaged Projects must
558 submit a patch to include themselves in the final distribution pom.xml file no
559 later than one week before RC0. Projects should only be added to the final
560 distribution pom.xml after they have published artifacts with the release job
561 to avoid breaking the build.
562
563 Unmanaged Release Process
564 -------------------------
565
566 Unmanaged Projects are free to follow their own processes. To have their
567 artifacts included in the final distribution, they need only follow the
568 Requirements for Unmanaged Projects above by the deadlines. Note that Unmanaged
569 Projects will not have any leeway for missing deadlines. If projects are not
570 in the final distribution by one week before RC0 their artifacts will not be
571 included in the final release, but they may still publish artifacts and help
572 their consumers install them out-of-band.
573
574 Checkpoints
575 +++++++++++
576
577 There are no checkpoints for Unmanaged Projects.
578
579 Moving a Project from Managed to Unmanaged
580 ------------------------------------------
581
582 Managed Projects that are not required for dependency reasons can submit a
583 **Project_Plan** issue to be Unmanaged to the TSC project in Jira. See details
584 in the `Initial Checkpoint`_ section above. Requests should be submitted before
585 the start of a release. Requests will be evaluated by the TSC.
586
587 The TSC may withdraw a project from the Managed Release at any time.
588
589 Installing Features from Unmanaged Projects
590 -------------------------------------------
591
592 Unmanaged Projects will have their artifacts included in the final release if
593 they are available on-time, but they will not be available to be installed
594 until the user does a repo:add.
595
596 To install an Unmanaged Project feature, find the feature description in the
597 system directory. For example, NetVirt's main feature:
598
599 system/org/opendaylight/netvirt/odl-netvirt-openstack/0.6.0-SNAPSHOT/
600
601 Then use the Karaf shell to repo:add the feature:
602
603 feature:repo-add mvn:org.opendaylight.netvirt/odl-netvirt-openstack/0.6.0
604 -SNAPSHOT/xml/features
605
606 Grievances
607 ==========
608
609 For requirements that are difficult to automatically ascertain if a Managed
610 Project is following or not, there should be a clear reporting process.
611
612 Grievance reports should be filed against the TSC project in Jira. Very urgent
613 grievances can additionally be brought to the TSC's attention via the TSC's
614 mailing list.
615
616 Process for Reporting Unresponsive Projects
617 -------------------------------------------
618
619 If a Managed Project does not meet the `Responsiveness`_ Requirements, a
620 **Grievance** issue should be filed against the TSC project in Jira.
621
622 Unresponsive project reports should include (at least):
623
624 * Select the project being reported in the **ODL_Project** field
625
626 * Select the release version in the **ODL_Release** field
627
628 * In the **Summary** field, put something like:
629   ``Grievance against Project-X``
630
631 * In the **Description** field, fill in the details:
632
633   .. code-block:: none
634
635      Document the details that show ExampleProject was slow to review a change.
636      The report should include as much relevant information as possible,
637      including a description of the situation, relevant Gerrit change IDs and
638      relevant public email list threads.
639
640 * In the **ODL_Gerrit_Patch**, put in a URL to a Gerrit patch, if applicable
641
642 Release Schedule
643 ================
644
645 The start date for odd release is September 7 and the start date for even
646 release is March 7.
647
648 .. list-table::
649    :widths: 20 20 20 40
650    :header-rows: 1
651    :stub-columns: 1
652
653    * - **Milestone**
654      - **Time**
655      - **Fluorine**
656      - **Description**
657
658    * - Release Start
659      - Start Date
660      - 2018-03-07
661      - Declare Intention: Submit **Project_Plan** Jira item in TSC project
662
663    * - Initial Checkpoint
664      - Start Date + 2 weeks
665      - 2018-03-22
666      - Initial Checkpoint. All Managed Projects must have completed
667        **Project_Plan** Jira items in TSC project.
668
669    * - Release Integrated Deadline
670      - Initial Checkpoint + 2 weeks
671      - 2018-04-07
672      - Deadline for Release Integrated Projects (currently ODLPARENT and
673        YANGTOOLS) to provide the desired version deliverables for downstream
674        Snapshot Integrated Projects to consume.
675
676    * - Version Bump
677      - Release Integrated Deadline + 1 day
678      - 2018-04-08
679      - Prepare version bump patches and merge them in (RelEng team). Spend the
680        next 2 weeks to get green build for all MSI Projects and a healthy
681        distribution.
682
683    * - Version Bump Checkpoint
684      - Release Integrated Deadline + 2 weeks
685      - 2018-04-21
686      - Check status of MSI Projects to see if we have green builds and a
687        healthy distribution. Revert the MRI deliverables if deemed necessary.
688
689    * - CSIT Checkpoint
690      - Version Bump Checkpoint + 2 weeks
691      - 2018-05-07
692      - All Managed Release CSIT should be in good shape - get all MSI Projects'
693        CSIT results as they were before the version bump. This is the final
694        opportunity to revert the MRI deliverables if deemed necessary.
695
696    * - Middle Checkpoint
697      - CSIT Checkpoint + 8 weeks
698      - 2018-07-05
699      - Checkpoint for status of Managed Projects - especially Snapshot
700        Integrated Projects.
701
702    * - Code Freeze
703      - Middle Checkpoint + 4 weeks
704      - 2018-08-07
705      - Code freeze for all Managed Projects - cut and lock release branch. Only
706        allow blocker bugfixes in release branch.
707
708    * - Final Checkpoint
709      - TSC meeting 2 weeks after Code Freeze
710      - 2018-08-23
711      - Final Checkpoint for all Managed Projects.
712
713    * - Formal Release
714      - 6 months after Start Date
715      - 2018-09-07
716      - Formal release
717
718    * - Service Release 1
719      - 1 month after Formal Release
720      - 2018-10-07
721      - Service Release 1 (SR1)
722
723    * - Service Release 2
724      - 2 months after SR1
725      - 2018-12-07
726      - Service Release 2 (SR2)
727
728    * - Service Release 3
729      - 2 months after SR2
730      - 2019-02-07
731      - Service Release 3 (SR3)
732
733    * - Service Release 4
734      - 3 months after SR3
735      - 2019-05-07
736      - Service Release 4 (SR4) - final service release
737
738    * - Release End of Life
739      - 4 months after SR4
740      - 2019-09-07
741      - End of Life - coincides with the Formal Release of the current release+2
742        versions and the start of the current release+3 versions
743
744 Vocabulary Reference
745 ====================
746
747 * Managed Release Process: The release process described in this document.
748 * Managed Project: A project taking part in the Managed Release Process.
749 * Unmanaged Project: A project not taking part in the Managed Release Process.
750 * Simultaneous Release: Event wherein all Snapshot Integrated Project versions
751   are rewriten to release versions and release artifacts are produced.
752 * Snapshot Integrated Project: Project that integrates with OpenDaylight
753   projects using snapshot version numbers. These projects release together in
754   the Simultaneous Release.
755 * Release Integrated Project: Project that releases independently of the
756   Simultaneous Release. These projects are consumed by Snapshot Integrated
757   Projects based on release version numbers, not snapshot versions.
758
759 .. _Committer Removal Process: https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process