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>
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 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>
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
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
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
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
This updates the instructions for client and non-client lib freeze to
make sure all changes are captured in a final release. Also adds a
helper tool to separate out the two types of libs since they have
different deadlines.
Change-Id: I29ea73bcc5a9649d7d9c502ebc0a05c840e41484
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
There were some inaccuracies and some missing information for some of
the tasks to be performed between cycles.
Change-Id: I48af839c200b316c28185cd992a83c996dd740e4
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Relax release process for cycle-with-intermediary deliverables,
while still ensuring that:
- they are encouraged to release multiple times
- they are encouraged to switch to cycle-with-rcs if they
routinely only release once
- they are released at least once before RC1
Change-Id: I2c49559f113f938dfaefd925d5fcc49d60da5828
Allow list_deliverables to filter output to list only deliverables
that have not been released since a given date (--unreleased-since).
This will be useful to compile list of libraries to autorelease at
milestones, or check for cycle-with-intermediary services that may
need a refresh release.
Additionally, if --show-dates is provided, the dates for last releases
(or all releases if -a option is provided) will be retrieved (and
displayed if in verbose mode).
Retrieving release dates is done through querying opendev's API for
tag references and looking at committer dates, so it requires Internet
access and increases command run time. It is only enabled if
--show_dates or --unreleased-since are enabled.
Task: 35684
Change-Id: I00aff6703e85a00572edb363973c92b883a79456
For things like tempest-plugins, the cycle-with-intermediary model
is a bit overkill, especially now that we encourage multiple
intermediary releases to qualify.
Introduce a new 'cycle-automatic' model for deliverables that only
need to be released once, automatically at the end of the cycle.
This is limited to "other" or "tempest-plugin" deliverables.
Task: 31025
Change-Id: I83ff63cef18ae297013c3761a373078e580cf58b
There are many references to review.openstack.org, and while the
redirect should work, we can also go ahead and fix them.
Change-Id: I0d46b1a4e00c1775ea5e38d39e87bed99f6bbb2e
This updates our process guide to incorporate the updates and changes we
identified while going through all steps during the Denver PTG.
Change-Id: Ib91bea5f874880f37d4d0e90c111ae0b89efa9d4
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Simplify the instructions by providing a special script and then
update the instructions to refer to it.
Change-Id: Ibbcd422c06dc4aeb3df503f3c0f084b39d3bf0f7
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
This adds instructions to our process document on how to prepare for the
next release cycle once the current one is complete.
Change-Id: I6f958facbfd7043a565ca5c2c0dcbfd6b3d54ad5
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
For RC1 week the steps are roughly in chronological order.
In order to get cycle-highlights in time for the deadline,
move that point up.
Change-Id: I40fd38599b0851dd596f9669edd8d26ccedd8c2a
This is the first step to complete the process which doesn't hold
the whole series of tools available at our disposition in the repo.
Change-Id: I6468fb176d85d0b79cccf6746b8af7a127217b00
Cycle highlights are now a regular part of a release and should
be included in the process document so we can promote and
collect them in a routine manner.
Change-Id: I025c029469e3fae85485b87351da9ec487ff5c89
This script will compute a list of deliverables present in
governance but unknown to release management, for manual
processing.
Change-Id: Ibebf777911416d978ecea5ba8d7b25b211e7ae52
Adds descriptions and references to the cycle-with-rc model.
Change-Id: I734a9344ce6b2456611708e59bbdd32c0403400e
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Update process document to reflect changes in the cycle-trailing
deadline.
Change-Id: I428991368f02f2aeaa5dfb8303bbe4b040ba97b7
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Sometimes creating the branches immediately for projects can comes as a
surprise and cause a little extra work with backports when they have
critical fixes to include with a requirements FFE. To avoid some of
this, change the branch creation policy to allow it at freeze time but
do not enforce it as a requirement. Then create the branches for any
missed deliverables closer to the end of the cycle.
Change-Id: Ib6f4037c450a00080a5e9a2a7665c6ea4d112ba5
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>