Jump to: navigation, search

PTL Guide

Revision as of 18:37, 27 September 2013 by Zhigang (talk | contribs)

New PTL's guide to managing an OpenStack Project

This is intended to be a living document sharing the common conventions and mechanisms used in managing core projects within the OpenStack foundation.

What is a PTL?

Project Team Lead (?)

What it takes to be a PTL

Prerequisites

You should already familiar with contributing to OpenStack and tools related to making code updates and getting them in place, in particular:

Availability

The PTL is expected to have sufficient time to dedicate to interaction with the release team. That includes presence at the weekly meetings, but also extra availability on milestone and release weeks. The dates for milestones and releases being known well in advance, please make sure you have sufficient free time on those special weeks. If your job doesn't give you sufficient free time to dedicate to release management, please consider stepping down and let someone with more time on their hands taking over.

Interactions with the Release team

Participating to the weekly IRC meeting

The release manager will review the state of each project against the current position in the release cycle in the weekly OpenStack Meetings/ProjectMeeting.

For example, during the folsom-1 milestone development timeframe, he will review for Keystone:

Actions

A PTL should be on the meeting, or have a delegate that can report on progress, make calls to action, and generally be prepared to answer questions about the project from the general community.

Maintaining Cycle plans

The PTL is expected to produce and maintain general objectives for the development cycle in the cycle plan. This plan contains the blueprints that are expected to be worked on during the cycle. You can find it at blueprints.launchpad.net/PROJECT/CYCLE, for example for Nova in Essex: https://blueprints.launchpad.net/nova/essex.

You can add or remove blueprints in that plan by using the series goal field in the blueprints. Blueprints in the cycle plan should have an indicative milestone set, indicating when in the cycle the feature is expected to be completed. Blueprints in the cycle plan should also have an assignee: the person or development group that has committed to delivering the feature in OpenStack.

Maintaining Milestone plans

This cycle plan trickles down into milestone plans, for each milestone. Milestone plans appear at: launchpad.net/PROJECT/+milestone/MILESTONE, for example for Nova on essex-3: [1]]. When a milestone is in progress, it's important to keep the status of the blueprints accurate: the assignee is supposed to keep the status current, and the PTL to ensure that the status reflects reality. See the [[Blueprints blueprints field reference] for more details.

Maintaining Targeted bugs

The PTL can also target bugs that need to be fixed by a specific milestone. Those bugs will appear on the milestone plans, and be reviewed regularly during the weekly meetings.

Special actions on Milestone delivery week

Milestone-proposed cut (EOD Tuesday)

The deadline for merging new features is the end of the day on the Tuesday of the milestone delivery week. It is the responsibility of the PTL to make it so that at the end of the Tuesday, the milestone plan only contains Implemented or Deferred blueprints. If any blueprint is still open on the Wednesday, that means the PTL requires an (exceptional) deadline extension for that specific blueprint before the milestone-proposed branch is cut. So please make sure that list is reviewed and updated before the end of your Tuesday !

By Tuesday EOD, the targeted bug list should also be cured into a list of release-critical bugs. Bugs that will not be fixed in the next two days (or that have no assignee) should be untargeted (or moved to the next milestone). This bug list becomes a don't release before those bugs are fixed list, so it should be kept as small as possible.

A few hours after EOD, the milestone-proposed branch is cut. This branch is for bugfixes only. Bugs that are fixed in master are set to FixCommitted, bugs that are fixed in milestone-proposed are set to FixReleased. The last build of milestone-proposed becomes the milestone delivery.

Backporting fixes to milestone-proposed (Wednesday/Thursday)

Release-blocking bugs should be:

  1. targeted to the milestone
  2. merged in master branch (FixCommitted)
  3. backported to milestone-proposed
  4. merged in milestone-proposed (FixReleased)

Changes proposed to milestone-proposed can be accepted by PTLs and the release manager. The policy for accepting those changes is to doublecheck that the fix is targeted to the milestone, and has landed in master first.

Instructions on backporting changes can be found here.

Milestone day (EOD Thursday)

The buglist on the milestone plan becomes a way to communicate with the release team. If the buglist is all FixReleased, that means the milestone can be released by the release team, starting on Thursday morning. If there are bugs left, they act as a blocker until they are fixed in milestone-proposed, or untargeted. It is the PTL responsibility to make sure that the list accurately represents the "releasability" of their project :)

Please plan to be extra available on release cut day, the success of a milestone depends on it.

Special actions during the RC period

At the end of the cycle, after the last milestone, we enter the release candidates period.

We use release candidate milestone pages to track the work that's left to do before we can issue the release candidate. All known release blockers must be targeted to the RC milestone. Once that list is empty, we can publish a release candidate (RC1). This release candidate will be used as the release, unless a release-critical bug is found that warrants a release candidate respin. After RC1 the master branch is reopened for development, and only release-critical bugs are backported to the release branch.

Release-critical bugs that may trigger a respin should be tagged series-rc-potential (for example folsom-rc-potential), and are reviewed by the PTL and the release manager to see if they are worth a respin. As time passes, we get more picky about what should trigger a respin and what should be documented as a known issue. If a respin is warranted, we open a new milestone page to track the work to complete before the new RC can be proposed.

Interacting with Launchpad

Teams

Each core project has a project on launchpad:

  • https://launchpad.net/projectname
  • links to Code, Documentation and Community pages
  • references to bugs and blueprints
  • shows series, milestones, and links to corresponding release deliverables

Each project typically has multiple teams associated with it (the same person :

 - folks responsible for maintaining the roadmap and objectives
 - can manage milestones, blueprints and blueprint settings
 - includes the PTL and anybody the PTL delegate this authority to
 - can set importance and specific statuses to bugs
 - core devs from Gerrit and LP -drivers team are generally part of it

There is also a generic ~projectname team (https://launchpad.net/~projectname) but it's not really used for anything.

Bugs

https://bugs.launchpad.net/projectname

Receiving bug reports and specific, (ideally reproducible) problems from the community. Anyone can open a bug report against a project.

Bugs can be used to indicate small-sized feature additions or work tasks as well. Since bugs can be tagged (where blueprints can't), bugs can be a useful medium for triaging and working against lists of issues to achieve a specific goal.

A single bug in Launchpad can have multiple bug tasks, which can be project tasks or series tasks. Project tasks are used to track tasks necessary to fix the bug across several projects (so you can have a single bug affecting multiple OpenStack projects). Series tasks are also used to track backport work: you can nominate the bug for a given past series to track the completion of the backport of a bug to a stable/* branch. See here for an example.

Bugs are generally completely open. A special case of bug report is a security vulnerability. In general, these bugs are submitted as embargoed security bugs and only the reporter and the OpenStack VulnerabilityManagement team see these bugs initially. Access is controlled through bug "subscription". The PTL of the affected project is quickly added to the access list, and additional folks can be subscribed from any of the people currently able to see the issue. As soon as possible, embargoed security issues are unembargoed and accessible by everyone.

Please learn the meaning of the different fields in a bug (status, importance...) at: Bugs

By default, bugs sort of importance, and then status - so setting the importance higher implies that they're more important to get solved.

Bugs (unlike blueprints) can be tagged with ad-hoc tags as well, and then those tags searched or filtered on. You can see official tags at: BugTags.

Another important field is the milestone associated with the bug. Bugs associated with a milestone mean that they're intended to be closed in that milestone. Later in a release cycle, a milestone "cut" will be blocked by open bugs associated with that milestone.

Actions

A PTL should plan to review all new bugs on a frequent basis - at least weekly:

Just prior to a milestone release, a PTL should go through all the bugs and associate any that are "in progress" and likely to be fully committed by the release, or in "fix committed" state to the milestone.

Blueprints

https://blueprints.launchpad.net/projectname

Intended to be feature requests or project efforts. A blueprint may require one or more code commits to complete. Anyone can propose a blueprint. Blueprints have a priority, a "design state", a delivery status, an assignee, and can be associated with a series and/or milestone.

Please learn the meaning of the different fields in a blueprint at: Blueprints

A blueprint is also used to propose features, and are typically used as discussion points for future features in OpenStack Design Summits. To propose a feature, an individual should create a blueprint, assign themselves (Assignee) to the blueprint, and then be prepared to discuss or develop how the feature may be created and implemented.

Actions

A PTL should set importance and map to milestones on all blueprints at the beginning of a release cycle to make a map of how they expect the project to progress.

Just prior to a milestone, the PTL should review the blueprints and update delivery progress as well as update milestone settings if a blueprint is going to slip.

Answers

Ask OpenStack is the preferred way for community to ask for support. Anyone can open a question, and anyone can answer a question. Questions can be tagged by the project name, usually tagging is done by the person asking and/or by Ask moderators.

Answers can be linked to an existing bug report using the syntax lp:BUGNUMBER.

Actions

A PTL should plan to review open questions on a frequent basis - at least weekly: