Managed Release¶

Responsiveness¶

Managed Projects should be responsive over email, IRC, Gerrit, Jira and in regular meetings.

All committers should be subscribed to their project’s mailing list and the release mailing list.

For the following particularly time-sensitive events, an appropriate response is expected within two business days.

• RC or SR candidate feedback.
• Major disruptions to other projects where a Jira weather item was not present and the pending breakage was not reported to the release mailing list.

If anyone feels that a Managed Project is not responsive, a grievance process is in place to clearly handle the situation and keep a record for future consideration by the TSC.

Active Committers¶

Managed Projects should have sufficient active committers to review contributions in a timely manner, support potential contributors, keep CSIT healthy and generally effectively drive the project.

If a project that the TSC deems is critical to the Managed Release is shown to not have sufficient active committers the TSC may step in and appoint additional committers. Projects that can be dropped from the Managed Release will be dropped instead of having additional committers appointed.

Managed Projects should regularly prune their committer list to remove inactive committers, following the Committer Removal Process.

TSC Attendance¶

Managed Projects are required to send a representative to attend TSC meetings.

To facilitate quickly acting on problems identified during TSC meetings, representatives must be a committer to the project they are representing. A single person can represent any number of projects.

Representatives will make the following entry into the meeting minutes to record their presence:

#project <project ID>

TSC minutes will be scraped per-release to gather attendance statistics. If a project does not provide a representative for at least half of TSC meetings a grievance will be filed for future consideration.

Initial Checkpoint¶

An initial checkpoint will be collected two weeks after the start of each release. The release team will review the information collected and report it to the TSC at the next TSC meeting.

Projects will need to create the following artifacts:

• High-level, human-readable description of what the project plans to do in this release. This should be submitted as a Jira Project Plan issue against the TSC project.

  • Select your project in the ODL Project field

  • Select the release version in the ODL Release field

  • Select the appropriate value in the ODL Participation field: SNAPSHOT_Integrated (Managed) or RELEASE_Integrated (Managed)

  • Select the value Initial in the ODL Checkpoint field

  • In the Summary field, put something like: Project-X Fluorine Release Plan

  • In the Description field, fill in the details of your plan:

    This should list a high-level, human-readable summary of what a project
    plans to do in a release. It should cover the project's planned major
    accomplishments during the release, such as features, bugfixes, scale,
    stability or longevity improvements, additional test coverage, better
    documentation or other improvements. It may cover challenges the project
    is facing and needs help with from other projects, the TSC or the LFN
    umbrella. It should be written in a way that makes it amenable to use
    for external communication, such as marketing to users or a report to
    other LFN projects or the LFN Board.
    

• If a project is transitioning from Self-Managed to Managed or applying for the first time into a Managed release, raise a Jira Project Plan issue against the TSC project highlighting the request.

  • Select your project in the ODL Project field

  • Select the release version in the ODL Release field

  • Select the NOT_Integrated (Self-Managed) value in the ODL Participation field

  • Select the appropriate value in the ODL New Participation field: SNAPSHOT_Integrated (Managed) or RELEASE_Integrated (Managed)

  • In the Summary field, put something like: Project-X joining/moving to Managed Release for Fluorine

  • In the Description field, fill in the details using the template below:

    Summary
    This is an example of a request for a project to move from Self-Managed
    to Managed. It should be submitted no later than the start of the
    release. The request should make it clear that the requesting project
    meets all of the Managed Release Requirements.
    
    Healthy Community
    The request should make it clear that the requesting project has a
    healthy community. The request may also highlight a history of having a
    healthy community.
    
    Responsiveness
    The request should make it clear that the requesting project is
    responsive over email, IRC, Jira and in regular meetings. All committers
    should be subscribed to the project's mailing list and the release
    mailing list. The request may also highlight a history of
    responsiveness.
    
    Active Committers
    The request should make it clear that the requesting project has a
    sufficient number of active committers to review contributions in a
    timely manner, support potential contributors, keep CSIT healthy and
    generally effectively drive the project. The requesting project should
    also make it clear that they have pruned any inactive committers. The
    request may also highlight a history of having sufficient active
    committers and few inactive committers.
    
    TSC Attendance
    The request should acknowledge that the requesting project is required
    to send a committer to represent the project to at least 50% of TSC
    meetings. The request may also highlight a history of sending
    representatives to attend TSC meetings.
    
    Checkpoints Submitted On-Time
    The request should acknowledge that the requesting project is required
    to submit checkpoints on time. The request may also highlight a history
    of providing deliverables on time.
    
    Jobs Required for Managed Projects Running
    The request should show that the requesting project has the required
    jobs for Managed Projects running and healthy. Links should be provided.
    
    Depend only on Managed Projects
    The request should show that the requesting project only depends on
    Managed Projects.
    
    Documentation
    The request should acknowledge that the requesting project is required
    to produce a user guide, developer guide and release notes for each
    release. The request may also highlight a history of providing quality
    documentation.
    
    CLM
    The request should acknowledge that the requesting project is required
    to handle Component Lifecycle Violations in a timely manner. The request
    should show that the project's CLM job is currently healthy. The request
    may also show that the project has a history of dealing with CLM
    violations in a timely manner.
    

• If a project is transitioning from Managed to Self-Managed, raise a Jira Project Plan issue against the TSC project highlighting the request.

  • Select your project in the ODL Project field

  • Select the release version in the ODL Release field

  • Select the appropriate value in the ODL Participation field: SNAPSHOT_Integrated (Managed) or RELEASE_Integrated (Managed)

  • Select the NOT_Integrated (Self-Managed) value in the ODL New Participation field

  • In the Summary field, put something like: Project-X Fluorine Joining/Moving to Self-Manged for Fluorine

  • In the Description field, fill in the details:

    This is a request for a project to move from Managed to Self-Managed. It
    should be submitted no later than the start of the release. The request
    does not require any additional information, but it may be helpful for
    the requesting project to provide some background and their reasoning.
    

• Weather items that may impact other projects should be submitted as Jira issues. For a weather item, raise a Jira Weather Item issue against the TSC project highlighting the details.

  • Select your project in the ODL Project field
  • Select the release version in the ODL Release field
  • For the ODL Impacted Projects field, fill in the impacted projects using label values - each label value should correspond to the respective project prefix in Jira, e.g. netvirt is NETVIRT. If all projects are impacted, use the label value ALL.
  • Fill in the expected date of weather event in the ODL Expected Date field
  • Select the appropriate value for ODL Checkpoint (may skip)
  • In the Summary field, summarize the weather event
  • In the Description field, provide the details of the weather event. Provide as much relevant information as possible.

The remaining artifacts will be automatically scraped:

• Blocker bugs that were raised between the previous code freeze and release.
• Grievances raised against the project during the last release.

Midway Checkpoint¶

One month before code freeze, a midway checkpoint will be collected. The release team will review the information collected and report it to the TSC at the next TSC meeting. All information for midway checkpoint will be automatically collected.

• Open Jira bugs marked as blockers.
• Open Jira issues tracking weather items.
• Statistics about jobs. * Autorelease failures per-project. * CLM violations.
• Grievances raised against the project since the last checkpoint.

Since the midway checkpoint is fully automated, the release team may collect this information more frequently, to provide trends over time.

Final Checkpoint¶

At 2 weeks after code freeze a final checkpoint will be collected by the release team and presented to the TSC at the next TSC meeting.

Projects will need to create the following artifacts:

• High-level, human-readable description of what the project did in this release. This should be submitted as a Jira Project Plan issue against the TSC project. This will be reused for external communication/marketing for the release.

  • Select your project in the ODL Project field

  • Select the release version in the ODL Release field

  • Select the appropriate value in the ODL Participation field: SNAPSHOT_Integrated (Managed) or RELEASE_Integrated (Managed)

  • Select the value Final in the ODL Checkpoint field

  • In the Summary field, put something like: Project-X Fluorine Release details

  • In the Description field, fill in the details of your accomplishments:

    This should be a high-level, human-readable summary of what a project
    did during a release. It should cover the project's major
    accomplishments, such as features, bugfixes, scale, stability or
    longevity improvements, additional test coverage, better documentation
    or other improvements. It may cover challenges the project has faced
    and needs help in the future from other projects, the TSC or the LFN
    umbrella. It should be written in a way that makes it amenable to use
    for external communication, such as marketing to users or a report to
    other LFN projects or the LFN Board.
    

  • In the ODL Gerrit Patch field, fill in the Gerrit patch URL to your project release notes

• Release notes, user guide, developer guide submitted to the docs project.

The remaining artifacts will be automatically scraped:

• Open Jira bugs marked as blockers.
• Open Jira issues tracking weather items.
• Statistics about jobs. * Autorelease failures per-project.
• Statistics about patches. * Number of patches submitted during the release. * Number of patches merged during the release. * Number of reviews per-reviewer.
• Grievances raised against the project since the start of the release.