Difference between revisions of "Heat/PTLGuide"
(Stable release policy) |
|||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 3: | Line 3: | ||
== OpenStack Responsibilities == | == OpenStack Responsibilities == | ||
| − | The PTL is accountable to the OpenStack community (and, in particular, the Technical Committee) for ensuring that the program fulfills the requirements of an OpenStack program. Read the [ | + | The PTL is accountable to the OpenStack community (and, in particular, the Technical Committee) for ensuring that the program fulfills the requirements of an OpenStack program. Read the [http://docs.openstack.org/project-team-guide/ Project Team Guide] for details. |
== Gerrit Groups == | == Gerrit Groups == | ||
| − | === | + | === Release Group === |
| − | The PTL should be a member of the [https://review.openstack.org/#/admin/groups/152,members `heat- | + | The PTL should be a member of the [https://review.openstack.org/#/admin/groups/152,members `heat-release` group] (formerly `heat-ptl`) in Gerrit, which is the group allowed to approve backported patches on stable branches. Get the previous PTL to add you. Keeping past PTLs in this group is actually encouraged (this means no single point of failure, at a potential cost of a higher chance of someone accidentally approving a backported patch). |
| + | |||
| + | There's also a [https://review.openstack.org/#/admin/groups/113,members `heat-milestone`] group that the PTL will need to be a member of once release candidates are out. We should probably consolidate the two groups, but for now you can just get the release manager to add you. | ||
=== Heat Core Team === | === Heat Core Team === | ||
| Line 19: | Line 21: | ||
If someone is added to core immediately before Summit, ensure that they receive an invitation to the Core Contributor Party. | If someone is added to core immediately before Summit, ensure that they receive an invitation to the Core Contributor Party. | ||
| + | |||
| + | == Releases == | ||
| + | |||
| + | The PTL is generally responsible for tagging releases in consultation with the release management team. There are generally three development milestones during a cycle that get tagged, followed by release candidates and a final release. The process for tagging a release involves submitting [https://review.openstack.org/#/q/project:openstack/releases a review to the releases repo]. | ||
| + | |||
| + | === Stable Releases === | ||
| + | |||
| + | The procedure for stable releases is the same as for milestones. | ||
| + | |||
| + | At milestone 1 of the development cycle, we should cut a release for the stable branch of the previous major release. At all milestones we should consider whether we ought to cut a release from any of the supported stable branches, based on the number and nature of fixes that have gone in since the previous stable release. | ||
== Design Summit Organisation == | == Design Summit Organisation == | ||
| Line 26: | Line 38: | ||
== Mid-cycle Meetup == | == Mid-cycle Meetup == | ||
| − | The Heat project has grown to the point where there is strong demand for a mid-cycle meetup. Experience in Juno has shown that after the Summit is too late to start organising a meetup, particularly in the summer when many people will have begun making holiday plans. The PTL should start canvassing for potential dates and locations prior to the Summit. | + | The Heat project has grown to the point where there is strong demand for a mid-cycle meetup. Experience in Juno has shown that after the Summit is too late to start organising a meetup, particularly in the summer when many people will have begun making holiday plans. The PTL should start canvassing for potential dates and locations prior to the Summit. Rackspace has offered to host, and Red Hat may well be open to doing so again. However, consider co-ordinating with other related projects, e.g. TripleO, to hold a combined meetup. |
Latest revision as of 16:20, 31 August 2016
This page is intended to collect information on the duties of the Program Technical Lead for Orchestration.
Contents
OpenStack Responsibilities
The PTL is accountable to the OpenStack community (and, in particular, the Technical Committee) for ensuring that the program fulfills the requirements of an OpenStack program. Read the Project Team Guide for details.
Gerrit Groups
Release Group
The PTL should be a member of the `heat-release` group (formerly `heat-ptl`) in Gerrit, which is the group allowed to approve backported patches on stable branches. Get the previous PTL to add you. Keeping past PTLs in this group is actually encouraged (this means no single point of failure, at a potential cost of a higher chance of someone accidentally approving a backported patch).
There's also a `heat-milestone` group that the PTL will need to be a member of once release candidates are out. We should probably consolidate the two groups, but for now you can just get the release manager to add you.
Heat Core Team
The PTL generally acts behind the scenes to collect feedback on various potential members for the Heat/CoreTeam, and can co-ordinate with candidates to ensure that they are interested and have the time available, as well as give them feedback in private on what they need to work on. If a candidate is approved by the core team, add them to the `heat-core` group in Gerrit.
In addition, core team members should also be members of the heat-drivers group in Launchpad so that they can approve and set priorities for blueprints. Get an existing administrator to add you as an administrator of the group, then add any new members.
To ensure the correct designation of core team members in the review statistics, you should also update the reviewstats tool with the appropriate Gerrit username. The easiest way to find the right username is by looking at the stats.
If someone is added to core immediately before Summit, ensure that they receive an invitation to the Core Contributor Party.
Releases
The PTL is generally responsible for tagging releases in consultation with the release management team. There are generally three development milestones during a cycle that get tagged, followed by release candidates and a final release. The process for tagging a release involves submitting a review to the releases repo.
Stable Releases
The procedure for stable releases is the same as for milestones.
At milestone 1 of the development cycle, we should cut a release for the stable branch of the previous major release. At all milestones we should consider whether we ought to cut a release from any of the supported stable branches, based on the number and nature of fixes that have gone in since the previous stable release.
Design Summit Organisation
The PTL is the only person with access to conduct the scheduling of the Design Summit sessions for Heat. It is recommended to use an Etherpad to collect feedback, and to start early because the timeframe is very tight between when submissions close and when the sessions need to be scheduled.
Mid-cycle Meetup
The Heat project has grown to the point where there is strong demand for a mid-cycle meetup. Experience in Juno has shown that after the Summit is too late to start organising a meetup, particularly in the summer when many people will have begun making holiday plans. The PTL should start canvassing for potential dates and locations prior to the Summit. Rackspace has offered to host, and Red Hat may well be open to doing so again. However, consider co-ordinating with other related projects, e.g. TripleO, to hold a combined meetup.
