Manila Project Team Lead guide

A project team lead for Manila is elected from the project contributors. A candidate for PTL needn’t be a core reviewer on the team, but, must be a contributor, and be familiar with the project to lead the project through its release process. If you would like to be a core reviewer begin by Contacting the Core Team. All the responsibilities below help us in maintaining the project. A project team lead can perform any of these or delegate tasks to other contributors.

General Responsibilities

Release cycle activities

  • Get acquainted with the release schedule and set Project specific milestones in the OpenStack Releases repository

  • Ensure the Manila Cross Project Liaisons are aware of their duties and are plugged into the respective areas

  • Acknowledge community wide cycle goals and find leaders and coordinate with the goal liaisons

  • Plan team activities such as:

    • Documentation day/s to groom documentation bugs and re-write release cycle docs

    • Bug Triage day/s to ensure the bug backlog is well groomed

    • Bug Squash day/s to close bugs

    • Collaborative Review meeting/s to perform a high-touch review of a code submission over a synchronous call

  • Milestone driven work:

    • Milestone-1:

      • Request a release for the python-manilaclient and manila-ui

      • Retarget any bugs whose fixes missed Milestone-1

    • Milestone-2:

      • Retarget any bugs whose fixes missed Milestone-2

      • Create a review priority etherpad and share it with the community and have reviewers sign up

    • Milestone-3:

      • Groom the release notes for python-manilaclient and add a ‘prelude’ section describing the most important changes in the release

      • Request a final cycle release for python-manilaclient

      • Retarget any bugs whose fixes missed Milestone-3

      • Grant/Deny any Feature Freeze Exception Requests

      • Update task trackers for Community Wide Goals

      • Write the cycle-highlights in marketing-friendly sentences and propose to the openstack/releases repo. Usually based on reno prelude but made more readable and friendly

      • Create the launchpad series and milestones for the next cycle in manila, python-manilaclient and manila-ui. Examples:

    • Before RC-1:

      • Groom the release notes for manila-ui and add a ‘prelude’ section describing the most important changes in the release

      • Request a final cycle release for manila-ui

      • Groom the release notes for manila, add a ‘prelude’ section describing the most important changes in the release

      • Mark bugs as {release}-rc-potential bugs in launchpad, ensure they are targeted and addressed by RC

    • RC-1:

      • Request a RC-1 release for manila

      • Request a final cycle tagged release for manila-tempest-plugin

      • Ensure all blueprints for the release have been marked “Implemented” or are re-targeted

    • After RC-1:

      • Close the currently active series on Launchpad for manila, python-manilaclient and manila-ui and set the “Development Focus” to the next release. Alternatively, you can switch this on the series page by setting the next release to “active development”

      • Set the last series status in each of these projects to “current stable branch release”

      • Set the previous release’s series status to “supported”

      • Move any Unimplemented specs in the specs repo to “Unimplemented”

      • Create a new specs directory in the specs repo for the next cycle so people can start proposing new specs

  • You should NOT plan to have more than one RC. RC2 should only happen if there was a mistake and something was missed for RC-1, or a new regression was discovered

  • Periodically during the release:

    • Every Week:

      • Coordinate the weekly Community Meeting agenda

      • Coordinate with the Bug Czar and ensure bugs are properly triaged

      • Check whether any bug-fixes must be back-ported to older stable releases

    • Every 3 weeks:

      • Ensure stable branch releases are proposed in case there are any release worthy changes. If there are only documentation or CI/test related fixes, no release for that branch is necessary

  • To request a release of any manila deliverable:

    • git checkout {branch-to-release-from}

    • git log --no-merges {last tag}..

      • Examine commits that will go into the release and use it to decide whether the release is a major, minor, or revision bump according to semver

    • Then, propose the release with version according to semver x.y.z

      • X - backward-incompatible changes

      • Y - features

      • Z - bug fixes

    • Use the new-release command to generate the release

    Note

    When proposing new releases, ensure that the releases for newer branches are proposed and accepted in the order of the most recent branch to the older.

Project Team Gathering

  • Create etherpads for PTG planning, cycle retrospective and PTG discussions and announce the Planning etherpad to the community members via the Manila community meeting as well as the OpenStack Discuss Mailing List

  • If the PTG is a physical event, gather an estimate of attendees and request the OpenDev Foundation staff for appropriate meeting space. Ensure the sessions are remote attendee friendly. Coordinate A/V logistics

  • Set discussion schedule and find an owner to run each proposed discussion at the PTG

  • All sessions must be recorded, nominate note takers for each discussion

  • Sign up for group photo at the PTG (if applicable)

  • After the event, send PTG session summaries and the meeting recording to the OpenStack Discuss Mailing List

Summit

  • Prepare the project update presentation. Enlist help of others

  • Prepare the on-boarding session materials. Enlist help of others