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 Managed Release Integrated Release Process
 462 ------------------------------------------
 463
 464 Managed Projects that release independently (Release Integrated Projects),
 465 not as a part of the Simultaneous Release with Snapshot Integrated Projects,
 466 will need to follow a different release process.
 467
 468 Managed Release Integrated (MRI) Projects will provide the releases they want
 469 the Managed Snapshot Integrated (MSI) Projects to consume no later than two
 470 weeks after the start of the Managed Release. The TSC will decide by a majority
 471 vote whether to bump MSI versions to consume the new MRI releases. This should
 472 happen as early in the release as possible to get integration woes out of the
 473 way and allow projects to focus on developing against a stable base. If the TSC
 474 decide to consume the proposed MRI releases, all MSI Projects are required to
 475 bump to the new versions within a two day window. If some projects fail to
 476 merge version bump patches in time, the TSC will instruct Linux Foundation
 477 staff to temporarily wield committer rights and merge version bump patches.
 478 The TSC vote at any time to back out of a version bump if the new releases are
 479 found to be unsuitable.
 480
 481 MRI Projects are expected to provide bugfixes via minor or patch version
 482 updates during the release, but should strive to not expect MSI Projects to
 483 consume another major version update during the release.
 484
 485 MRI Projects are free to follow their own release cadence as they develop new
 486 features during the Managed Release. They need only have a stable version ready
 487 for the MSI Projects to consume by the next integration point.
 488
 489 Managed Release Integrated Checkpoints
 490 ++++++++++++++++++++++++++++++++++++++
 491
 492 The MRI Projects will follow similar checkpoints as the MSI Projects, but the
 493 timing will be different. At the time MRI Projects provide the releases they
 494 wish MSI Projects to consume for the next release, they will also provide their
 495 final checkpoints. Their midway checkpoints will be scraped one month before
 496 the deadline for them to deliver their artifacts to the MSI Projects. Their
 497 initial checkpoints will be due no later two weeks following the deadline for
 498 their delivery of artifacts to the MSI Projects. Their initial checkpoints will
 499 cover everything they expect to do in the next Managed Release, which may
 500 encompass any number of major version bumps for the MRI Projects.
 501
 502 Moving a Project from Self-Managed to Managed
 503 ---------------------------------------------
 504
 505 Self-Managed Projects can request to become Managed by submitting a
 506 **Project_Plan** issue to the TSC project in Jira. See details as described
 507 under the `Initial Checkpoint`_ section above. Requests should be submitted
 508 before the start of a release. The requesting project should make it clear that
 509 they meet the Managed Release Project Requirements.
 510
 511 The TSC will evaluate requests to become Managed and inform projects of the
 512 result and the TSC's reasoning no later than the start of the release or one
 513 week after the request was submitted, whichever comes last.
 514
 515 For the first release, the TSC will bootstrap the Managed Release with projects
 516 that are critical to the OpenDaylight platform. Other projects will need to
 517 follow the normal application process defined above.
 518
 519 The following projects are deemed critical to the OpenDaylight platform:
 520
 521 * aaa
 522 * controller
 523 * infrautils
 524 * mdsal
 525 * netconf
 526 * odlparent
 527 * yangtools
 528
 529 Self-Managed Projects
 530 =====================
 531
 532 In general there are two types of Self-Managed (SM) projects:
 533
 534 #. Self-Managed projects that want to participate in the formal (major or
 535    service) OpenDaylight release distribution. This section includes the
 536    requirements and release process for these projects.
 537
 538 #. Self-Managed projects that want to manage their own release schedule
 539    or provide their release distribution and installation instructions
 540    by the time of the release. There are no specific requirements for
 541    these projects.
 542
 543 Requirements for SM projects participating in the release distribution
 544 ----------------------------------------------------------------------
 545
 546 Use of SNAPSHOT versions
 547 ++++++++++++++++++++++++
 548
 549 Self-Managed Projects can consume whichever version of their upstream dependencies
 550 they want during most of the release cycle, but if they want to be included in the
 551 formal (major or service) release distribution they must have their upstream
 552 versions bumped to SNAPSHOT and build successfully no later than one week before
 553 the first Managed release candidate (RC) is created. Since bumping and integrating
 554 with upstream takes time, it is strongly recommended Self-Managed projects start
 555 this work early enough. This is no later than the middle checkpoint if they want
 556 to be in a major release, or by the previous release if they want to be in a
 557 service release (e.g. by the major release date if they want to be in SR1).
 558
 559 .. note:: To help with the integration effort, the `Weather Page`_ includes API and
 560           other important changes during the release cycle. After the formal release,
 561           the release notes also include this information.
 562
 563 Add to Common Distribution
 564 ++++++++++++++++++++++++++
 565
 566 In order to be included in the formal (major or service) release distribution,
 567 Self-Managed Projects must be in the common distribution pom.xml file and the
 568 distribution sanity test (see :ref:`add-proj-dist`) no later than one week before
 569 the first Managed release candidate (RC) is created. Projects should only be added
 570 to the final distribution pom.xml after they have succesfully published artifacts
 571 using upstream SNAPSHOTs. See `Use of SNAPSHOT versions`_.
 572
 573 .. note:: It is very important Self-Managed projects do not miss the deadlines for
 574           upstream integration and final distribution check, otherwise there are
 575           high chances for missing the formal release distribution. See
 576           `Release the project artifacts`_.
 577
 578 Cut Stable Branch
 579 +++++++++++++++++
 580
 581 Self-Managed projects wanting to use the existing release job to release their
 582 artifacts (see `Release the project artifacts`_) must have an stable branch in
 583 the major release (fluorine, neon, etc) they are targeting. It is highly recommended
 584 to cut the stable branch before the first Managed release candidate (RC) is created.
 585
 586 After creating the stable branch Self-Managed projects should:
 587
 588 * Bump master branch version to X.Y+1.0-SNAPSHOT, this way any new merge in master
 589   will not interfere with the new created stable branch artifacts.
 590
 591 * Update .gitreview for stable branch: change defaultbranch=master to stable branch.
 592   This way folks running "git review" will get the right branch.
 593
 594 * Update their jenkins jobs: current release should point to the new created stable
 595   branch and next release should point to master branch. If you do not know how to
 596   do this please open a ticket to opendaylight helpdesk.
 597
 598 Release the project artifacts
 599 +++++++++++++++++++++++++++++
 600
 601 Self-Managed projects wanting to participate in the formal (major or service) release
 602 distribution must release and publish their artifacts to nexus in the week after the
 603 Managed release is published to nexus.
 604
 605 Self-Managed projects having an stable branch with latest upstream SNAPSHOT (see
 606 previous requirements) can use the release job in :doc:`project-release` to release
 607 their artifacts.
 608
 609 After creating the release, Self-Managed projects should bump the stable branch
 610 version to X.Y.Z+1-SNAPSHOT, this way any new merge in the stable branch will not
 611 interfere with pre-release artifacts.
 612
 613 .. note:: Self-Managed Projects will not have any leeway for missing deadlines. If
 614           projects are not in the final distribution in the allocated time (normally
 615           one week) after the Managed projects release, they will not be included
 616           in the release distribution.
 617
 618 Checkpoints
 619 +++++++++++
 620
 621 There are no checkpoints for Self-Managed Projects.
 622
 623 Moving a Project from Managed to Self-Managed
 624 ---------------------------------------------
 625
 626 Managed Projects that are not required for dependency reasons can submit a
 627 **Project_Plan** issue to be Self-Managed to the TSC project in Jira. See details
 628 in the `Initial Checkpoint`_ section above. Requests should be submitted before
 629 the start of a release. Requests will be evaluated by the TSC.
 630
 631 The TSC may withdraw a project from the Managed Release at any time.
 632
 633 Installing Features from Self-Managed Projects
 634 ----------------------------------------------
 635
 636 Self-Managed Projects will have their artifacts included in the final release
 637 if they are available on-time, but they will not be available to be installed
 638 until the user does a repo:add.
 639
 640 To install an Self-Managed Project feature, find the feature description in the
 641 system directory. For example, NetVirt's main feature:
 642
 643 system/org/opendaylight/netvirt/odl-netvirt-openstack/0.6.0-SNAPSHOT/
 644
 645 Then use the Karaf shell to repo:add the feature:
 646
 647 feature:repo-add mvn:org.opendaylight.netvirt/odl-netvirt-openstack/0.6.0
 648 -SNAPSHOT/xml/features
 649
 650 Grievances
 651 ==========
 652
 653 For requirements that are difficult to automatically ascertain if a Managed
 654 Project is following or not, there should be a clear reporting process.
 655
 656 Grievance reports should be filed against the TSC project in Jira. Very urgent
 657 grievances can additionally be brought to the TSC's attention via the TSC's
 658 mailing list.
 659
 660 Process for Reporting Unresponsive Projects
 661 -------------------------------------------
 662
 663 If a Managed Project does not meet the `Responsiveness`_ Requirements, a
 664 **Grievance** issue should be filed against the TSC project in Jira.
 665
 666 Unresponsive project reports should include (at least):
 667
 668 * Select the project being reported in the **ODL_Project** field
 669
 670 * Select the release version in the **ODL_Release** field
 671
 672 * In the **Summary** field, put something like:
 673   ``Grievance against Project-X``
 674
 675 * In the **Description** field, fill in the details:
 676
 677   .. code-block:: none
 678
 679      Document the details that show ExampleProject was slow to review a change.
 680      The report should include as much relevant information as possible,
 681      including a description of the situation, relevant Gerrit change IDs and
 682      relevant public email list threads.
 683
 684 * In the **ODL_Gerrit_Patch**, put in a URL to a Gerrit patch, if applicable
 685
 686 Vocabulary Reference
 687 ====================
 688
 689 * Managed Release Process: The release process described in this document.
 690 * Managed Project: A project taking part in the Managed Release Process.
 691 * Self-Managed Project: A project not taking part in the Managed Release
 692   Process.
 693 * Simultaneous Release: Event wherein all Snapshot Integrated Project versions
 694   are rewriten to release versions and release artifacts are produced.
 695 * Snapshot Integrated Project: Project that integrates with OpenDaylight
 696   projects using snapshot version numbers. These projects release together in
 697   the Simultaneous Release.
 698 * Release Integrated Project: Project that releases independently of the
 699   Simultaneous Release. These projects are consumed by Snapshot Integrated
 700   Projects based on release version numbers, not snapshot versions.
 701
 702 .. _Committer Removal Process: https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process
 703 .. _Weather Page: https://jira.opendaylight.org/browse/TSC-132?jql=Project%20%3D%20TSC%20AND%20Type%20%3D%20%22Weather%20Item%22%20