draft of presentation for rocky ptg
Change-Id: Ib5ec2f4a8f67d6c563daef2a0d2f7c4efc7bebe9 Signed-off-by: Doug Hellmann <doug@doughellmann.com>
This commit is contained in:
Doug Hellmann
parent
2ad5ffcdc9
commit
318bac66fa
|
|
@ -50,13 +50,240 @@ import re
|
|||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Create your other slides here</h2>
|
||||
<h2>Mission</h2>
|
||||
|
||||
<p>Coordinating the release of OpenStack deliverables, by
|
||||
defining the overall development cycle, release models,
|
||||
publication processes, versioning rules and tools, then
|
||||
enabling project teams to produce their own releases.</p>
|
||||
|
||||
<aside class="notes">
|
||||
Release schedule planning and coordination</br>
|
||||
</br>
|
||||
Assist teams producing deliverables: signed tarballs; announcements</br>
|
||||
</br>
|
||||
Communicate to users of deliverables: SemVer</br>
|
||||
</br>
|
||||
Maintaining release automation
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Not Responsible for</h2>
|
||||
|
||||
<ul>
|
||||
<li>Feature scheduling</li>
|
||||
<li>Feature tracking</li>
|
||||
<li>Prioritization of work</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>cycle-with-milestones</h2>
|
||||
|
||||
<ul>
|
||||
<li>commit to publish development milestones following a
|
||||
predetermined schedule</li>
|
||||
<li>commit to produce a release to match the end of the
|
||||
6-month development cycle</li>
|
||||
<li>used by service projects</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>cycle-with-intermediary</h2>
|
||||
|
||||
<ul>
|
||||
<li>produce multiple full releases during the cycle</li>
|
||||
<li>commit to produce a release near the end of the
|
||||
6-month development cycle</li>
|
||||
<li>used by libraries and service projects</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>cycle-trailing</h2>
|
||||
|
||||
<ul>
|
||||
<li>commit to produce a release no later than 2 weeks
|
||||
after the end of the 6-month development cycle</li>
|
||||
<li>within the cycle can follow milestones or produce
|
||||
intermediate releases</li>
|
||||
<li>used by deployment tools</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Before PTG</h2>
|
||||
<ul>
|
||||
<li>Establish and publish release schedule</li>
|
||||
</ul>
|
||||
|
||||
<aside class="notes">
|
||||
look for obviously bad times like major holidays, school starting, etc.</br>
|
||||
</br>
|
||||
coordinate with the foundation staff about when the PTG
|
||||
and summit will be held</br>
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Before Milestone 1</h2>
|
||||
<ul>
|
||||
<li>Make initial contact with PTLs</li>
|
||||
<li>Sign up release liaisons</li>
|
||||
</ul>
|
||||
|
||||
<aside class="notes">
|
||||
This is the only time we will reach out directly because
|
||||
there are 60+ of you and 3 of us.
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Staying in touch</h2>
|
||||
<ul>
|
||||
<li><tt>#openstack-release</tt> on freenode</li>
|
||||
<li><tt>[release]</tt> on openstack-dev@</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Before Milestone 2</h2>
|
||||
<ul>
|
||||
<li>First "warning" for projects that missed the
|
||||
milestone</li>
|
||||
<li>Why do milestones apply to everyone?</li>
|
||||
</ul>
|
||||
|
||||
<aside class="notes">
|
||||
|
||||
milestones give us a cadence for checking in with all
|
||||
teams</br>
|
||||
</br>
|
||||
|
||||
gives us a way to break up the work over the course of the
|
||||
cycle in a consistent way, since all teams use the same
|
||||
milestones</br>
|
||||
</br>
|
||||
|
||||
missing is an early indicator for problems because the
|
||||
project team isn't paying attention to the schedule
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Before Milestone 3</h2>
|
||||
<ul>
|
||||
<li>Coordinate the library release freeze</li>
|
||||
<li>Update gerrit and the CI system to handle the new
|
||||
stable branches</li>
|
||||
<li>Coordinate requirements freeze</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Why do we want to release before the final cut-off?</h2>
|
||||
<ul>
|
||||
<li>Services are only tested with released libraries</li>
|
||||
<li>We need a place to create the stable branch</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Why do we freeze library releases?</h2>
|
||||
<ul>
|
||||
<li>Stability for consumers</li>
|
||||
<li>Downstream packagers</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Why are client and regular library freezes different?</h2>
|
||||
<ul>
|
||||
<li>Clients have late-landing features to support the
|
||||
service</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Why do we freeze the requirements list?</h2>
|
||||
<ul>
|
||||
<li>Stability for our CI</li>
|
||||
<li>Downstream packagers</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Before RC1</h2>
|
||||
<ul>
|
||||
<li>Make sure cycle-with-intermediary projects are
|
||||
thinking about the end of cycle coming up</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>At RC1</h2>
|
||||
<ul>
|
||||
<li>Ensure all projects are branched</li>
|
||||
<li>Coordinate updates and branching for devstack and
|
||||
grenade</li>
|
||||
<li>Coordinate branching of requirements list</li>
|
||||
</ul>
|
||||
|
||||
<aside class="notes">
|
||||
we need to branch together, at roughly the same time and
|
||||
in the right order, because otherwise the configuration
|
||||
for the CI system becomes too complicated (ensuring that
|
||||
the right versions of master and stable branches are
|
||||
combined for testing, using the right sets of requirements
|
||||
and constraints, etc.)
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Before Final</h2>
|
||||
<ul>
|
||||
<li>Publish a planned set of final releases for PTL and
|
||||
liaison review</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>At Final</h2>
|
||||
<ul>
|
||||
<li>Tag the final releases</li>
|
||||
<li>Coordinate with the docs team to publish the
|
||||
documentation</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Planned Changes for Rocky</h2>
|
||||
|
||||
<ul>
|
||||
<li>nudging library maintainers more often for
|
||||
releases</li>
|
||||
<li>nudging cycle-with-intermediary maintainers earlier
|
||||
for releases</li>
|
||||
<li>publishing all services to PyPI (under
|
||||
discussion)</li>
|
||||
</ul>
|
||||
|
||||
<aside class="notes">
|
||||
Trying to avoid a repeat of Rocky where we had late
|
||||
branches, late releases, etc.
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Resources</h2>
|
||||
<p><small>
|
||||
<a href="http://git.openstack.org/cgit/openstack-infra/release-tools/tree/presentation-6-months-in-the-life-of-openstack">openstack-infra/release-tools/presentation-6-months-in-the-life-of-openstack</a>
|
||||
<a href="http://git.openstack.org/cgit/openstack-infra/release-tools/tree/presentation-6-months-in-the-life-of-openstack">openstack-infra/release-tools/presentation-6-months-in-the-life-of-openstack
|
||||
</a>
|
||||
</small></p>
|
||||
<p><small>
|
||||
<a href="http://git.openstack.org/cgit/openstack/releases/tree/PROCESS.rst">openstack/releases/PROCESS.rst
|
||||
</a>
|
||||
</small></p>
|
||||
<p class="creativecommons">
|
||||
|
|
|
|||
Loading…
Reference in New Issue