tox -e venv -- init-series $SERIES $NEXT_SERIES

tox -e venv -- make-tracking-pad ussuri

This email is going out to all PTLs and release liaisons for $SERIES.

Welcome to the $SERIES series. On behalf of the release management team, I
just wanted to say hello and make sure you had the information you need
to know what to do and what to expect during this coming release cycle.

Release Schedule
================

If you haven't seen it yet, please take a look at the published schedule for
this cycle:

    https://releases.openstack.org/$SERIES/schedule.html

That lists all of the major milestones along the way as we work towards the
coordinated release on $release-date.

Community-wide deadlines are listed under the "Cross-project events" column.
You may notice some projects have added project-specific deadlines under the
"Project-specific events" column. That can be done by submitting a patch to the
openstack/releases repo updating the doc/source/$SERIES/schedule.* files, if
you would like to make sure those deadlines are published somewhere.

Countdown Emails
================

Throughout the cycle, we will be sending regular "countdown" emails to the
openstack-discuss mailing list. If you have filtering set up for mailing list
emails, please make sure you are not filtering out subject lines that contain
"[release]" and "[ptl]" tags.

These countdown emails will contain important updates on upcoming deadlines and
information about necessary actions throughout the cycle. We try to keep them
to a minimum, so earlier on in the cycle they will not be sent weekly, but
around deadline times and especially towards the end of the cycle, these will
go out weekly to make sure everyone has the information they need to get work
done in time. Your attention to these emails would be appreciated. We will try
to keep them short.

Deliverables
============

The release process may be new for a few of you. All official OpenStack
deliverables are released by updating deliverable files in the
openstack/releases repo:

    https://opendev.org/openstack/releases/src/branch/master/deliverables/$SERIES

Please take a look at your deliverable files and make sure the release-model
matches what the team plans to follow for this cycle. This model is a way to
communicate to downstream consumers what to expect, so the release team uses
your declared model to determine when and how to enforce different steps during
the cycle.

Details on the release models and what they mean, as well as documentation on
how to use the releases repo, can be found in the references section here:

    https://releases.openstack.org/index.html#references

That has documentation for some of our tooling too. The most important one you
may want to know about is the new-release tooling so you don't need to edit
those yaml files directly. That command can be used like this:

    tools/new_release.sh $SERIES cinder feature

The last part can be major (major version bump), feature (minor version bump),
and bugfix (bugfix, or the Z in X.Y.Z).

Reviews
=======

Because of the strict timing of the cycle schedule, it is important that you
review release patches within some days or usually until Thursdays EOB if
possible. Please look at the incoming review request emails (sent by gerrit)
from openstack/releases repository regularly or at least check your inbox at
least once or twice a week:

    https://review.opendev.org/q/project:openstack/releases+reviewer:self+is:open

The above link shows a customised list of release patches that only contains
patches that you are added as reviewer. Release managers use a script to add
PTLs and release liaisons to their relevant release patches as reviewers.

Release Liaisons
================

If anyone should be added as a release liaison, or removed, just submit a patch
to update the data/release_liaisons.yaml file in the openstack/releases repo
with current information for your team.


Please contact us at any point with any questions. We can be reached on the
openstack-discuss mailing list with the [release] tag, or on IRC in the
#openstack-release channel.

Thanks for your attention. I hope the $SERIES cycle goes well for everyone.

Welcome back to the release countdown emails! These will be sent at
major points in the $SERIES development cycle, which should conclude
with a final release on $release-date.

Development Focus
-----------------

At this stage in the release cycle, focus should be on planning the
$SERIES development cycle, assessing $SERIES community goals and approving
$SERIES specs.

General Information
-------------------

$remark-on-series-length. In case you haven't seen it yet, please take
a look over the schedule for this release:

https://releases.openstack.org/$SERIES/schedule.html

By default, the team PTL is responsible for handling the release cycle
and approving release requests. This task can (and probably should) be
delegated to release liaisons. Now is a good time to review release
liaison information for your team and make sure it is up to date:

https://opendev.org/openstack/releases/src/branch/master/data/release_liaisons.yaml

By default, all your team deliverables from the $PREVIOUS_SERIES release are
continued in $SERIES with a similar release model.

Upcoming Deadlines & Dates
--------------------------

$other-upcoming-event_
$SERIES-1 milestone: $milestone1

tox -e venv -- list-deliverables --series $LASTSERIES \
    --type trailing --missing-final

Development Focus
-----------------

The $SERIES-1 milestone is next week, on $milestone1! Project team plans
for the $SERIES cycle should now be solidified.

General Information
-------------------

Libraries need to be released at least once per milestone period. Next
week, the release team will propose releases for any library which had
changes but has not been otherwise released since the $LASTSERIES release.
PTL's or release liaisons, please watch for these and give a +1 to
acknowledge them. If there is some reason to hold off on a release, let
us know that as well, by posting a -1. If we do not hear anything at all
by the end of the week, we will assume things are OK to proceed.

NB: If one of your libraries is still releasing 0.x versions, start
thinking about when it will be appropriate to do a 1.0 version. The
version number does signal the state, real or perceived, of the library,
so we strongly encourage going to a full major version once things are
in a good and usable state.

Upcoming Deadlines & Dates
--------------------------

$SERIES-1 milestone: $milestone1

tools/aclissues.py ../project-config ../governance

Development Focus
-----------------

We are now past the $SERIES-1 milestone. Teams should now be focused on
feature development and completion of goals [0].

[0] https://governance.openstack.org/tc/goals/selected/index.html

General Information
-------------------

Our next milestone in this development cycle will be $SERIES-2, on
$milestone2. This milestone is when we freeze the list of deliverables
that will be included in the $SERIES final release, so if you plan to
introduce new deliverables in this release, please propose a change to
add an empty deliverable file in the deliverables/$SERIES directory of
the openstack/releases repository.

Now is also generally a good time to look at bugfixes that were
introduced in the master branch that might make sense to be backported
and released in a stable release.

If you have any question around the OpenStack release process, feel free
to ask on this mailing-list or on the #openstack-release channel on IRC.

Upcoming Deadlines & Dates
--------------------------

$SERIES-2 Milestone: $milestone2

Development Focus
-----------------

The $SERIES-2 milestone will happen in next month, on $milestone2.
$SERIES-related specs should now be finalized so that teams can move
to implementation ASAP. Some teams observe specific deadlines on
the second milestone (mostly spec freezes): please refer to
https://releases.openstack.org/$SERIES/schedule.html for details.

General Information
-------------------

Please remember that libraries need to be released at least once per
milestone period. At milestone 2, the release team will propose releases
for any library that has not been otherwise released since milestone 1.

Other non-library deliverables that follow the cycle-with-intermediary
release model should have an intermediary release before milestone-2.
Those who haven't will be proposed to switch to the cycle-with-rc model,
which is more suited to deliverables that are released only once per cycle.

At milestone-2 we also freeze the contents of the final release. If you
have a new deliverable that should be included in the final release, you
should make sure it has a deliverable file in:
https://opendev.org/openstack/releases/src/branch/master/deliverables/$series
You should request a beta release (or intermediary release) for those new
deliverables by milestone-2. We understand some may not be quite ready
for a full release yet, but if you have something minimally viable to
get released it would be good to do a 0.x release to exercise the release
tooling for your deliverables. See the MembershipFreeze description for
more details: https://releases.openstack.org/$SERIES/schedule.html#$S-mf

Finally, now may be a good time for teams to check on any stable
releases that need to be done for your deliverables. If you have
bugfixes that have been backported, but no stable release getting
those. If you are unsure what is out there committed but not released,
in the openstack/releases repo, running the command
"tools/list_stable_unreleased_changes.sh <cycle_name>" gives a nice report.

Upcoming Deadlines & Dates
--------------------------

$SERIES-2 Milestone: $milestone2

python3 tools/governance_consistency.py $series $project_yaml_file

Development Focus
-----------------

The $SERIES-2 milestone is next week, on $milestone2! $SERIES-related
specs should now be finalized so that teams can move to implementation
ASAP. Some teams observe specific deadlines on the second milestone
(mostly spec freezes): please refer to
https://releases.openstack.org/$SERIES/schedule.html for details.

General Information
-------------------

Libraries need to be released at least once per milestone period. Next
week, the release team will propose releases for any library that has not
been otherwise released since milestone 1. PTL's and release liaisons,
please watch for these and give a +1 to acknowledge them. If there is
some reason to hold off on a release, let us know that as well. A +1
would be appreciated, but if we do not hear anything at all by the end
of the week, we will assume things are OK to proceed.

Remember that non-library deliverables that follow the
cycle-with-intermediary release model should have an intermediary
release before milestone-2. Those who haven't will be proposed to switch
to the cycle-with-rc model, which is more suited to deliverables that
are released only once per cycle.

Next week is also the deadline to freeze the contents of the final
release. All new '$SERIES' deliverables need to have a deliverable file
in https://opendev.org/openstack/releases/src/branch/master/deliverables
and need to have done a release by milestone-2.

Changes proposing those deliverables for inclusion in $SERIES have been
posted, please update them with an actual release request before the
milestone-2 deadline if you plan on including that deliverable in $SERIES,
or -1 if you need one more cycle to be ready.

Upcoming Deadlines & Dates
--------------------------

$SERIES-2 Milestone: $milestone2

tox -e venv -- \
   list-deliverables \
       --unreleased-since YYYY-MM-DD \
       --model cycle-with-intermediary \
       --type client-library \
       --type library \
> /tmp/deliverables.log

tools/process_auto_releases.sh $SERIES $(cat /tmp/deliverables.log)

tools/aclissues.py ../project-config ../governance

Development Focus
-----------------

We are now past the $SERIES-2 milestone, and entering the last development
phase of the cycle. Teams should be focused on implementing planned work
for the cycle.

Now is a good time to review those plans and reprioritize anything if
needed based on the what progress has been made and what looks realistic
to complete in the next few weeks.

General Information
-------------------

Looking ahead to the end of the release cycle, please be aware of the
feature freeze dates. Those vary depending on deliverable type:

* General libraries (except client libraries) need to have their last
  feature release before Non-client library freeze ($nclfreeze). Their
  stable branches are cut early.

* Client libraries (think python-*client libraries) need to have their
  last feature release before Client library freeze ($milestone3)

* Deliverables following a cycle-with-rc model (that would be most
  services) observe a Feature freeze on that same date, $milestone3.
  Any feature addition beyond that date should be discussed on the
  mailing-list and get PTL approval. After feature freeze, cycle-with-rc
  deliverables need to produce a first release candidate (and a stable
  branch) before RC1 deadline ($rc1-deadline)

* Deliverables following cycle-with-intermediary model can release as
  necessary, but in all cases before Final RC deadline ($final-rc-deadline)

Upcoming Deadlines & Dates
--------------------------

Non-client library freeze: $nclfreeze (R-6 week)
Client library freeze: $milestone3 (R-5 week)
$SERIES-3 milestone: $milestone3 (R-5 week)
$other-upcoming-event

./tools/list_weeks.py t 2019-04-15 2019-10-16

tox -e venv -- list-deliverables --unreleased \
--model cycle-with-intermediary \
--type horizon-plugin --type other --type service

General Information
-------------------

The following cycle-with-intermediary deliverables have not done any
intermediary release yet during this cycle. The cycle-with-rc release
model is more suited for deliverables that plan to be released only once
per cycle. As a result, we have proposed[1] to change the release model
for the following deliverables:

[ list of deliverables ]

[1] https://review.opendev.org/#/q/topic:$series-cwi

PTLs and release liaisons for each of those deliverables can either +1
the release model change, or propose an intermediary release for that
deliverable. In absence of answer by the end of R-10 week we'll consider
that the switch to cycle-with-rc is preferable.

We also published a proposed release schedule for the upcoming
$nextseries cycle. Please check out the separate thread:

[ link to thread ]

Upcoming Deadlines & Dates
--------------------------

Non-client library freeze: $nclfreeze (R-6 week)
Client library freeze: $milestone3 (R-5 week)
$SERIES-3 milestone: $milestone3 (R-5 week)
$other-upcoming-event

Development Focus
-----------------

We are entering the last weeks of the $series development cycle. From
now until the final release, we'll send a countdown email like this
every week.

It's probably a good time for teams to take stock of their library and
client work that needs to be completed yet. The non-client library freeze
is coming up, followed closely by the client lib freeze. Please plan
accordingly to avoid any last minute rushes to get key functionality in.

General Information
-------------------

Next week is the Extra-AC freeze, in preparation for elections. All
contributions to OpenStack are valuable, but some are not expressed as
Gerrit code changes. Please list active contributors to your project team
who do not have a code contribution this cycle, and therefore won't
automatically be considered an Active Contributor and allowed
to vote. This is done by adding extra-acs to
https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml
before the Extra-AC freeze on $extraac.

A quick reminder of the upcoming freeze dates. Those vary depending on
deliverable type:

* Oslo libraries are entering feature freeze next week, $extraac.

* General libraries (except client libraries) need to have their last
feature release before Non-client library freeze ($nclfreeze). Their
stable branches are cut early.

* Client libraries (think python-*client libraries) need to have their
last feature release before Client library freeze ($milestone3)

* Deliverables following a cycle-with-rc model (that would be most
services) observe a Feature freeze on that same date, $milestone3. Any
feature addition beyond that date should be discussed on the mailing-list
and get PTL approval. After feature freeze, cycle-with-rc deliverables
need to produce a first release candidate (and a stable branch) before
RC1 deadline ($rc1-deadline)

* Deliverables following cycle-with-intermediary model can release as
necessary, but in all cases before Final RC deadline ($final-rc-deadline)

Finally, now is also a good time to start planning what highlights you
want for your deliverables in the cycle highlights. The deadline to
submit an initial version for those is set to one week after Feature
freeze ($highlights).

Background on cycle-highlights:
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125613.html
Project Team Guide, Cycle-Highlights:
https://docs.openstack.org/project-team-guide/release-management.html#cycle-highlights
jeremy [at] openstack.org/fungi on IRC is available if you need
help selecting or writing your highlights.

Upcoming Deadlines & Dates
--------------------------

Extra-AC freeze: $extraac (R-7 week)
Oslo feature freeze: $extraac (R-7 week)
Non-client library freeze: $nclfreeze (R-6 week)
Client library freeze: $milestone3 (R-5 week)
$SERIES-3 milestone: $milestone3 (R-5 week)
Cycle highlights deadline: $highlights (R-4 week)
$other-upcoming-event

Development Focus
-----------------

Work on libraries should be wrapping up, in preparation for the various
library-related deadlines coming up. Now is a good time to make decisions
on deferring feature work to the next development cycle in order to be
able to focus on finishing already-started feature work.

General Information
-------------------

We are now getting close to the end of the cycle, and will be gradually
freezing feature work on the various deliverables that make up the
OpenStack release.

This coming week is the deadline for general libraries (except client
libraries): their last feature release needs to happen before "Non-client
library freeze" on $nclfreeze. Only bugfixes releases will be allowed
beyond this point.

When requesting those library releases, you can also include the
stable/$series branching request with the review (as an example, see the
"branches" section here:
https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/os-brick.yaml#n2

In the next weeks we will have deadlines for:

* Client libraries (think python-*client libraries), which need to have
their last feature release before "Client library freeze" ($milestone3)

* Deliverables following a cycle-with-rc model (that would be most
services), which observe a Feature freeze on that same date, $milestone3.
Any feature addition beyond that date should be discussed on the
mailing-list and get PTL approval.

As we are getting to the point of creating stable/$series branches, this
would be a good point for teams to review membership in their
$project-stable-maint groups. Once the stable/$series branches are cut
for a repo, the ability to approve any necessary backports into those
branches for $series will be limited to the members of that stable team.
If there are any questions about stable policy or stable team membership,
please reach out in the #openstack-stable channel.

Upcoming Deadlines & Dates
--------------------------

Non-client library freeze: $nclfreeze (R-6 week)
Client library freeze: $milestone3 (R-5 week)
$SERIES-3 milestone: $milestone3 (R-5 week)
Cycle Highlights Due: $highlight (R-4 week)
$series final release: $release-date
$other-upcoming-event

Development Focus
-----------------

We are getting close to the end of the $series cycle! Next week on
$milestone3 is the $series-3 milestone, also known as feature freeze.
It's time to wrap up feature work in the services and their client
libraries, and defer features that won't make it to the $next-series cycle.

General Information
-------------------

This coming week is the deadline for client libraries: their last feature
release needs to happen before "Client library freeze" on $milestone3.
Only bugfix releases will be allowed beyond this point.

When requesting those library releases, you can also include the
stable/$series branching request with the review. As an example, see the
"branches" section here:
https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/os-brick.yaml#n2

$milestone3 is also the deadline for feature work in all OpenStack
deliverables following the cycle-with-rc model. To help those projects
produce a first release candidate in time, only bugfixes should be allowed
in the master branch beyond this point. Any feature work past that deadline
has to be raised as a Feature Freeze Exception (FFE) and approved by the
team PTL.

Finally, feature freeze is also a good time for submitting a first version
of your cycle-highlights. Cycle highlights are the raw data that helps shape
what is communicated in press releases and other release activity at the
end of the cycle, avoiding direct contacts from marketing folks. See
https://docs.openstack.org/project-team-guide/release-management.html#cycle-highlights
for more details.

Upcoming Deadlines & Dates
--------------------------

$series-3 milestone (feature freeze): $milestone3 (R-5 week)
RC1 deadline: $rc1-deadline (R-3 week)
Final RC deadline: $final-rc-deadline (R-1 week)
Final $SERIES release: $release-date
$other-upcoming-event

tox -e venv -- list-deliverables --unreleased --type library --type client-library

tox -e venv -- list-deliverables --unreleased \
--model cycle-with-intermediary \
--type horizon-plugin --type other --type service

Quick reminder that we'll need a release very soon for a number of
deliverables following a cycle-with-intermediary release model but which
have not done *any* release yet in the $series cycle:

{{list-of-deliverables}}

Those should be released ASAP, and in all cases before $rc1-deadline, so
that we have a release to include in the final $series release.

Development Focus
-----------------

We just passed feature freeze! Until release branches are cut, you
should stop accepting featureful changes to deliverables following the
cycle-with-rc release model, or to libraries. Exceptions should be
discussed on separate threads on the mailing-list, and feature freeze
exceptions approved by the team's PTL.

Focus should be on finding and fixing release-critical bugs, so that
release candidates and final versions of the $series deliverables can be
proposed, well ahead of the final $series release date.

General Information
-------------------

We are still finishing up processing a few release requests, but the
$series release requirements are now frozen. If new library releases are
needed to fix release-critical bugs in $series, you must request a
Requirements Freeze Exception (RFE) from the requirements team before we
can do a new release to avoid having something released in $series that
is not actually usable. This is done by posting to the openstack-discuss
mailing list with a subject line similar to:

        [$PROJECT][requirements] RFE requested for $PROJECT_LIB

Include justification/reasoning for why a RFE is needed for this lib.
If/when the requirements team OKs the post-freeze update, we can then
process a new release.

A soft String freeze is now in effect, in order to let the I18N team do the
translation work in good conditions. In Horizon and the various dashboard
plugins, you should stop accepting changes that modify user-visible
strings. Exceptions should be discussed on the mailing-list. By
$rc-final-date this will become a hard string freeze, with no changes
in user-visible strings allowed.

Actions
-------

stable/$series branches should be created soon for all not-already-branched
libraries. You should expect 2-3 changes to be proposed for each: a
.gitreview update, a reno update (skipped for projects not using reno),
and a tox.ini constraints URL update. Please review those in priority
so that the branch can be functional ASAP.

The Prelude section of reno release notes is rendered as the top level
overview for the release. Any important overall messaging for $series
changes should be added there to make sure the consumers of your release
notes see them.

Upcoming Deadlines & Dates
--------------------------

RC1 deadline: $rc1-deadline (R-3 week)
Final RC deadline: $final-rc-deadline (R-1 week)
Final $SERIES release: $release-date
$other-upcoming-event

tox -e venv -- list-deliverables --unreleased-since YYYY-MM-DD \
--model cycle-with-intermediary \
--type horizon-plugin --type other --type service

Quick reminder that for deliverables following the cycle-with-intermediary
model, the release team will use the latest $series release available on
release week.

The following deliverables have done a $series release, but it was not
refreshed in the last two months:

 {{list_of_deliverables}}

You should consider making a new one very soon, so that we don't use an
outdated version for the final release.

Development Focus
-----------------

The Release Candidate (RC) deadline is next Thursday, $rc1-deadline. Work
should be focused on fixing any release-critical bugs.

General Information
-------------------

All deliverables released under a cycle-with-rc model should have a first
release candidate by the end of the week, from which a stable/$series
branch will be cut. This branch will track the $series release.

Once stable/$series has been created, the master branch will be ready to
switch to $next-series development. While the master branch will no longer
be feature-frozen, please prioritize any work necessary for completing
$series plans.  Release-critical bugfixes will need to be merged in the
master branch first, then backported to the stable/$series branch before
a new release candidate can be proposed.

Actions
-------

Early in the week, the release team will be proposing RC1 patches for all
cycle-with-rc projects, using the latest commit from the master branch.
If your team is ready to go for cutting RC1, please let us know by
leaving a +1 on these patches.

If there are still a few more patches needed before RC1, you can -1 the
patch and update it later in the week with the new commit hash you would
like to use. Remember, stable/$series branches will be created with this,
so you will want to make sure you have what you need included to avoid
needing to backport changes from the master branch (which will
technically then be $next-series) to this stable branch for any
additional RCs before the final release.

The release team will also be proposing releases for any deliverable
following a cycle-with-intermediary model that has not produced any $series
release so far.

Finally, now is a good time to finalize release highlights. Release
highlights help shape the messaging around the release and make sure that
your work is properly represented.

Upcoming Deadlines & Dates
--------------------------

RC1 deadline: $rc1-deadline (R-3 week)
Final RC deadline: $final-rc-deadline (R-1 week)
Final $SERIES release: $release-date
$other-upcoming-event

Development Focus
-----------------

At this point we should have release candidates (RC1 or recent intermediary
release) for all the $series deliverables. Teams should be working on any
release-critical bugs that would require another RC or intermediary release
before the final release.

Actions
-------

Early in the week, the release team will be proposing stable/$series branch
creation for all deliverables that have not branched yet, using the latest
available $series release as the branch point. If your team is ready to go
for creating that branch, please let us know by leaving a +1 on these
patches.

If you would like to wait for another release before branching, you can -1
the patch and update it later in the week with the new release you would
like to use. By the end of the week the release team will merge those
patches though, unless an exception is granted.

Once stable/$series branches are created, if a release-critical bug is
detected, you will need to fix the issue in the master branch first, then
backport the fix to the stable/$series branch before releasing out of the
stable/$series branch.

After all of the cycle-with-rc projects have branched we will branch
devstack, grenade, and the requirements repos. This will effectively open
them up for $next-series development, though the focus should still be on
finishing up $series until the final release.

Opening up the new development cycle is also a good opportunity to teams
to revise their zuul jobs and used nodesets and clean up all unnecessary
ones.

For projects with translations, watch for any translation patches coming
through and merge them quickly. A new release should be produced so that
translations are included in the final $series release.

Finally, now is a good time to finalize release notes. In particular,
consider adding any relevant "prelude" content. Release notes are
targetted for the downstream consumers of your project, so it would be
great to include any useful information for those that are going to pick
up and use or deploy the $series version of your project.

Upcoming Deadlines & Dates
--------------------------

Final RC deadline: $final-rc-deadline (R-1 week)
Final $SERIES release: $release-date
$other-upcoming-event

tools/add_release_note_links.sh $series

Development Focus
-----------------

We are on the final mile of the $series development cycle!

Remember that the $series final release will include the latest release
candidate (for cycle-with-rc deliverables) or the latest intermediary
release (for cycle-with-intermediary deliverables) available.

$final-rc-deadline is the deadline for final $series release candidates
as well as any last cycle-with-intermediary deliverables. We will then
enter a quiet period until we tag the final release on $release-date.
Teams should be prioritizing fixing release-critical bugs, before that
deadline.

Otherwise it's time to start planning the $next-series development cycle,
including discussing Forum and PTG sessions content, in preparation of
$other-upcoming-event.

Actions
-------

Watch for any translation patches coming through on the stable/$series
branch and merge them quickly. If you discover a release-critical issue,
please make sure to fix it on the master branch first, then backport the
bugfix to the stable/$series branch before triggering a new release.

Please drop by #openstack-release with any questions or concerns about
the upcoming release !

Upcoming Deadlines & Dates
--------------------------

Final $SERIES release: $release-date
$other-upcoming-event

Development Focus
-----------------

We will be releasing the coordinated OpenStack $series release next week,
on $release-date. Thanks to everyone involved in the $series cycle!

We are now in pre-release freeze, so no new deliverable will be created
until final release, unless a release-critical regression is spotted.

Otherwise, teams attending the PTG in $ptg-location should start to plan
what they will be discussing there, by creating and filling team etherpads.
You can access the list of PTG etherpads at:

http://ptg.openstack.org/etherpads.html

General Information
-------------------

On release day, the release team will produce final versions of
deliverables following the cycle-with-rc release model, by re-tagging
the commit used for the last RC.

A patch doing just that will be proposed. PTLs and release liaisons should
watch for that final release patch from the release team. While not
required, we would appreciate having an ack from each team before we
approve it on the 16th, so that their approval is included in the metadata
that goes onto the signed tag.

Upcoming Deadlines & Dates
--------------------------

Final $SERIES release: $release-date
$other-upcoming-event

tools/add_release_note_links.sh $SERIES

tox -e venv -- missing-releases --series $SERIES