docs/release-process/managed-release.rst

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