The release team has a few cases now where we need to propose release
patches for a large set of deliverables. Due to differences in semver
choice based on actually merged commits, along with other decisions that
need to be made while doing these, this process can't be completely
automated. But this adds a script that will automate the majority of the
process to simplify it as much as possible.
Change-Id: I6ec9fa77baab58df93bdadc0ac3c3fa5d3e18804
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Devstack-gate has been restructured since we added references to patches
to show what needs to be done to prepare for new stable branches. This
is a trivial update to point to a more recent review that is a better
example of what needs to be done.
Change-Id: Iacffaf3dce12b3aaea113d057d497e19970d0fc2
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This does a new release with release-test to see if everything is
covered to allow branches to have a bugfix/* prefix.
Change-Id: I7869cf412524d7352249f02f7449b2fddf401d2c
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Information about adding a deliverable should live in the
general usage documentation, not the release models page.
Also stop advising projects to release independently if they
get added after the second milestone of a series, as it creates
issues down the road with inconsistent stale pages in the
'Independent' section.
Change-Id: I9319656b62b063d637737ad8667d3099f179fb58
Now that releases are systematically proposed for deliverables with
changes at the end of a cycle, the cycle-automatic release model is
really better described with cycle-with-intermediary combined with
the 'stable-branch-type: none' option.
Change-Id: Ia9c5dadcaa89fbbdb7420a52cc3fed665e4ba513
Cycle-trailing deliverables are regular cycle-following deliverables,
using RCs or not not using RCs -- they just have a different deadline.
Rather than using a release model, those deadline variants are better
described using deliverable types, in much the same way 'library'
deliverables have a specific deadline too.
This simplifies the list of models significantly, and allows to have
proposer validation of trailing deliverables that use RCs or not use
RCs.
For compatibility in old branches, setting 'cycle-trailing' is still
supported, it will just overload the type to 'trailing' if specified.
Change-Id: Ifce88ef3e5dd406f45f25214699f16e736ad5377
This adds a new std-with-versions branch type. This is used to control
validation logic when branching to allow the Ironic team to create
intermediary stable branches based on major.minor version numbers in
addition to our normal expected stable/$series branches.
https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/new-release-model.html
Change-Id: Ic482c77a2c177162ffe37643a455ac1724a658b3
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This adds some steps to be done as we near the end of a development
cycle to make sure we are ready when stable branches are created.
Change-Id: I56ae71a6d9869ab138c256d9d3021dfd8fd1402e
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This adds a script that will go through all release reviews under a
given review topic, find the PTL and release liaisons for the owning
teams of those releases, and add them as reviewers to the patch.
Change-Id: I6294c1d9da7d6a977df6d8460aa085d2cc7e72a5
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
The new governance_consistency.py tool lists all inconsistencies
between deliverables defined in openstack/releases and deliverables
defined in openstack/governance. Using it instead of the
membership_freeze_test tool (which only listed deliverables defined
in governance that did not have a corresponding deliverable file)
gives us the chance to fix all inconsistencies before milestone-2.
Change-Id: I34c2454082054b6e49edf16784e0e9213799ecc1
Now that ussuri-2 is past us, update the process to add
weekly email content that was posted during those weeks.
Change-Id: I738a1678e7a236ce8fb30de25978bac6a2db680a
In releases.o.o we display signature links for all deliverables,
if the series is > Ocata or independent. Since some "independent"
deliverables predate the signature generation tooling, that results
in a number of "independent" deliverables displaying broken signature
links, which makes us look bad.
This adds a flag (skipped-sig) that can be set for independent
deliverables that did not have any signature generated (pre-Ocata), and
skips the signature link display if the flag is set.
As a practical example, this fixes broken links for PBR<2. Tony signed
up to automatically generate the others.
Change-Id: I44a49e3f08010a85c64673d2292528139eabcc99
get-contacts:
To extract the PTL/Liaison contact information from the governance data
/ release team data
tools/bulk_review.sh:
To manipulate a dirty working-tree and post as a single gerrit topic,
one change per team. Changes are unordered so any change can be merged
when it's ready/ approved by the appropriate team
Also enhance get-deliverable-owner: to detect file paths
Story: 2005704
Task: 31028
Change-Id: Ia319e8a7b4da195cb4bc861c51025a41adc43bb3
Introduce an 'abandoned' release model for cycle-independent
deliverables. It should only be applied to deliverables in the
_independent directory. No new release should be accepted for
deliverables with this release-model.
Change-Id: I65c163888c37f7a7f77273abf3ca0633923a0fe2
Update process based on what happened in the weeks before and after
ussuri-1.
NB: actions around governance/releases consistency checks will be added
later, when the tool is ready and standing issues are resolved.
Change-Id: I046fd116c8d91bb6707855c9ba489b8d5791b45b
The propose-update-constraints job was referred to as
propose-upper-constraints. Update name to make it a little easier if
someone is looking for references to the actual job.
Change-Id: I707b2a498af491c9d2e481ed1880ad74839c9389
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This is the first step into automating PTL/liaison approval.
This tool will check that PTL/liaisons either authored the change or
approved it.
Change-Id: I1bbb371997e9e92f39eff47adb4d3d176af35de7
Move R+1 week process items to the top of the document, remove obsolete
steps and merge the remaning ones with pre-PTG steps. Include weekly
email content. Move the step about proposing a schedule for the next
release to "between m-2 and m-3", as this is when we actually do that.
Change-Id: I5a4a7e5e059156139944a09e4d7813bd11ec1c5a
This updates the instructions in the process document to point at the
new home in the data files rather than the old wiki location.
Change-Id: I68a25d80edfc933ff9685846ad62f194a19c4043
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Refine process based on what happened in R-1 for Train,
and adjust process based on what is planned for R+0
Include the template for the R+0 release weekly email.
Change-Id: Iabb57b47a5ec37248733526c709d7011636df414
It took a non-trivial amount of effort to turn our process into
actionable items for every week of our team tracker. Start
reformatting R-6 to R-4 based on what we just did for Train.
Change-Id: I53189c838875836d030062fa1fd71ba7f0ae1eff
To render command-line options correctly, they should be quoted in
double backticks. This change fixes formatting for `new-release` command
options.
Change-Id: Iebbd2994d5ded61beb9f308656b7779482ce9d16
This is not clear what release-test is for.
I expected the repo to be used for final release, as a canary
test. I expected things had to done with it beforehand.
But I only got a confirmation through IRC (as this is not yet documented
in the process), that it only serves during RC/final release time.
This should clarify it.
Change-Id: I9ba636a8a3147466a1e661c074a050ff14a6d394