diff --git a/specs/policy/ptl.rst b/specs/policy/ptl.rst new file mode 100644 index 0000000..ecfc198 --- /dev/null +++ b/specs/policy/ptl.rst @@ -0,0 +1,207 @@ +=========== + PTL Guide +=========== + +There are some Oslo-specific aspects to being the Oslo PTL. This document is +a place to capture those for future reference. + +Problem Description +=================== + +Each PTL learns things about the position during the time in which they serve +it. However, historically they've kept private notes that had to be passed +along from PTL to PTL, which is not ideal. First, if the handoff doesn't happen +for any reason, the new PTL will have to start over from scratch. Second, it +makes these notes hidden from public view, which is not useful for potential +future PTL candidates. + +Proposed Policy +=============== + +This should be a living document that is updated by PTLs as they discover +new best practices and tips for leading the Oslo project. + +A new or future PTL should first read the `Project Team Guide PTL Document`_. +It contains a wealth of useful information that a PTL should know. Pay +particular attention to the parts about delegating. + +Releases +-------- +In general, the PTL or release liaison should propose releases for all Oslo +libraries that need one weekly. Generally this is done early in the week, and +releasing on Friday is avoided when possible to avoid anyone having to work +the weekend to fix a breakage. If a critical fix needs to be released +immediately, it does not have to wait for the regular weekly release cycle. +The intent of the weekly cycle is to ensure changes get released in a timely +fashion, not to prevent anything from being released. + +Exceptions to the weekly release schedule can be made at the discretion of the +PTL. Releasing immediately before a holiday when most of the team will not be +around is not ideal. It is also a good idea to wait to release master after a +new stable branch has been cut until the release associated with the stable +branch has shipped. This allows backports of things like dependency bumps in +case bugs are found during final testing of an OpenStack release. In that case, +a minor version bump would be needed and if master has already been released +then that minor version will already be taken. + +.. note:: In general, minor version changes are not allowed on stable branches, + but exceptions can be made if the situation warrants it. + +When making releases, there are some useful commands to know. First, to find +all the changes in all the Oslo libraries since they were last released, use +the following commands in the openstack/releases repo:: + + ./tools/list_unreleased_changes.sh master $(.tox/venv/bin/list-deliverables --team oslo -r) + ./tools/list_unreleased_changes.sh master $(.tox/venv/bin/list-deliverables --team oslo -r --series independent) + +.. note:: These commands assume that the ``venv`` tox environment has been + created. That can be done with the command ``tox -e venv --notest`` + +.. note:: Oslo contains both libraries that are tied to the OpenStack release + as well as some that are independent of it. That's why two commands + are needed to cover all of them. + +To do the same for a stable branch, use the following (replace the branch names +as appropriate):: + + ./tools/list_unreleased_changes.sh stable/train $(.tox/venv/bin/list-deliverables --team oslo -r --series train) + +Meetings +-------- +The Oslo team typically meets weekly. The specific day and time can be found +on the `eavesdrop page`_. The PTL normally chairs the meeting, but other +contributors can also do so if desired or needed. The `meeting agenda`_ +can be found on the wiki page. Chairing the meeting involves going through +the topics in the agenda - some weeks this takes 15 minutes or less, others +it takes the full hour or more. + +Ping List +--------- +The Oslo team uses a courtesy ping list in the `meeting agenda template`_ so +regular meeting attendees can be reminded of the start of the meeting. +Attendees can add or remove their names as desired and the person running +the weekly meeting should copy the ping list into IRC so everyone on the list +gets a notification. + +Weekly Wayward Review +--------------------- + +This meeting topic requires a bit more explanation. The idea is to find an old +review and move it along in some way. This means at the end of the meeting, +the review should either be approved, -1'd, or have someone assigned to follow +up after the meeting. + +bnemec uses `reviewstats`_ to find the oldest open reviews in Oslo. + +Beginning of Cycle Activities +----------------------------- + +* The ping list should be cleared each cycle to avoid pinging people who no + longer work on Oslo. A new ping list can be created in parallel to the old + one to allow contributors who want to stay on the list to sign up before the + list is cleared. These parallel lists should both exist for a couple of weeks + to give everyone a chance to update the new one. + +* When a new release name is announced, it needs to be added to the oslo.log + versionutils module. + +* At the start of each cycle, the Oslo `feature freeze`_ date should be added + to the release calendar. See this `feature freeze date review`_ for an + example of doing that. + +* Check the `oslo-coresec`_ group and make sure all members are active Oslo + cores so private security bugs are not being sent out to people who don't + need to see them. If necessary, add current core team members to ensure + that there are enough people on the coresec team to handle any security bugs + that come in. + + For more details on managing the coresec team, see the + `vulnerability management team's requirements`_. + +End of Cycle Activities +----------------------- + +* Make sure all libraries get released before non-client library freeze, even + if they don't have changes that would normally prompt a release (such as + doc or test changes). This may be handled automatically by the release team + now, but it's still good to do it explicitly. It is important for all changes + to be released before stable branches are cut because branches are based on + the last released commit, not what was on master at the time. If there are + unreleased doc or test changes they may be lost on the stable branch and need + to be backported. + +* Manually request a stable branch for the devstack-plugin repos. Because these + are not released, they are not automatically branched. For details on how to + do this, see this `branch request`_ change. + +PTL Handoff Activities +---------------------- + +Hopefully most of these activities are automated, but one thing that needs to +be done manually is to make the new PTL an administrator on the +`oslo-coresec`_ group in Launchpad. + + +.. _`Project Team Guide PTL Document`: https://docs.openstack.org/project-team-guide/ptl.html +.. _`eavesdrop page`: http://eavesdrop.openstack.org/#Oslo_Team_Meeting +.. _`meeting agenda`: https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting +.. _`meeting agenda template`: https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_Template +.. _`reviewstats`: https://opendev.org/openstack/reviewstats +.. _`feature freeze`: http://specs.openstack.org/openstack/oslo-specs/specs/policy/feature-freeze.html +.. _`feature freeze date review`: https://github.com/openstack/releases/commit/58585a1fa0084fb8aca8146c848d338ccc7766ba#diff-6590df7965d3a63150e201d8881d33f9 +.. _`vulnerability management team's requirements`: https://governance.openstack.org/tc/reference/tags/vulnerability_managed.html#requirements +.. _`branch request`: https://review.openstack.org/#/c/650118/ +.. _`oslo-coresec`: https://launchpad.net/~oslo-coresec + +Alternatives & History +====================== + +As discussed in the problem description, we could continue to have the Oslo +PTL maintain a private set of notes that is passed individually to the next +PTL. This is not preferred for the reasons mentioned there. + +Implementation +============== + +Author(s) +--------- + +Primary author: + bnemec + +Other contributors: + Future PTLs + +Milestones +---------- + +N/A + +Work Items +---------- + +Writing the policy itself is the main work item. Updating it as the community +evolves will be an ongoing process. + +References +========== + +`Ussuri community goal `_ + +Revision History +================ + +.. list-table:: Revisions + :header-rows: 1 + + * - Release Name + - Description + * - Ussuri + - Introduced + +.. note:: + + This work is licensed under a Creative Commons Attribution 3.0 + Unported License. + http://creativecommons.org/licenses/by/3.0/legalcode +