With the new option of the script (delete a branch) the documentation
is updated to express this as well.
Change-Id: I9445b4f8abff81c11a397a15a85cb1ffe1e5bfec
This tool will be used in doc addition around the branching period
to ensure that we don't miss to create stable branches for project.
Also this tooling should be used around each trailing deadline to ensure
to not forget a trailing projects. Trailing projects are those who can
easily meet the conditions that lead to forget to branch them.
Adding usage of this tooling in our process to ensure to check that
point once a time at each new series.
Change-Id: I2a8bd25ecfe5bb1bde5af16b08f897a5bdc11cb7
Add code and spec submission deadlines that the manila
project maintainers adhere to.
Change-Id: I58200d7b12c3a3cda7166da965619016d97f71ea
Signed-off-by: Douglas Viroel <viroel@gmail.com>
The doc is outdated and `list_library_unreleased_changes.sh` produce a
list of changes that can't be consumed directly by `process_auto_release`.
`list_library_unreleased_changes` should be updated to only provide
pojects name. `process_auto_release` already provide list of diff so we
don't need to duplicate that.
Also fixing a wrong command name.
Change-Id: I59e4adaf19095ec0569bf86ddf1e4b99f440dda2
Xena's schedule proposed a date for wallaby trailing projects these
changes update wallaby's agenda to highlight this.
Change-Id: Ice958c959a2c9c603868bd90870418181214351d
This is a 25 week schedule for the Xena release. Planned release date
is October 06, 2021.
Change-Id: Ibfaa75d9a567ca981653677ad66763662a2e177f
Signed-off-by: Hervé Beraud <hberaud@redhat.com>
These sentences seems wrong as we proposed many time to move release
models in the middle of the cycle.
Change-Id: I71cb18682761775894bf4f03ddc68f5b66335335
As discussed during one of our meeting few weeks ago here is the doc
related to the flag status process used by the release team to hold our
validations in the case where we face a repeatable issue.
Change-Id: Iafe0f01c8607cbb9e297cd4b99e099a31e471960
During milestone-2 we automatically propose to release each project
that haven't yet been released previously [1] so I think this section
of the email is useless.
This patch allow us to discuss about this.
[1] https://releases.openstack.org/reference/process.html#milestone-2
Change-Id: I0f55cada96e971c948f17333c3d4f19bcf5cc4eb
For testing for Extended Maintenance branches with branchless
Tempest and Tempest plugins, we need to release the new tag
for Tempest and its plugins as last compatible version for that
Extended Maintenance branches.
This commits adds the documentation and validation machinery changes about
that tag $series-last which will be used for branchless testing tooling.
Change-Id: I799e8e637a54a46fd7ca74dd568ea2c7506fa32d
Depends-On: https://review.opendev.org/c/openstack/project-team-guide/+/769821
From the website it is unclear how to find the data behind it.
Add a link to the openstack/releases repository in the introduction
of the Documentation section.
Change-Id: Iae94beae7d30d348157fc8fe3772d252bb29f154
Change pygments_style to 'native' since old theme version always used
'native' and the theme now respects the setting and using 'sphinx' can
lead to some strange rendering.
more info : http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014971.html
Change-Id: Ia6dafb44a140f8a5fd4f55682d9fb34967e7643c
Since transition from the EOL model to the EM model eol branches
are no longer removed and this step is no longer in the release team
process.
Keep stale branches can be an issue in some situation especially with
zuul and our gates. To avoid this situation the release team propose
to reintroduce regular checks to ensure that we remove stale branches
that have been tagged eol previously.
As discussed during our previous meetings soon it will be possible to design
a new job and to trigger it to remove eol branches automatically.
This will possible when the infra would have been updated and when all
the needed pieces will be in place.
Change-Id: I53aeb3211bb3251a3278472a514a39afe825cdd2
This sets the end date for the Victoria key, adds the Wallaby key
starting today and links to a minimal export of the corresponding
public key and its details on the keyserver network. This can be
amended with a new patchset or a follow-up change to correct the
included dates after the key material change (Depends-On below)
merges and goes into effect.
Change-Id: I97ca5ee0baf20a9470189fa621a1fa30115aeb15
Depends-On: https://review.opendev.org/760364
We have gerrit-dash-creator and https://tiny.cc/ReleaseInbox, but both
require manual steps to be taken by someone each time the status of a
series changes. Since we already capture series status data in a format
that is easily parsable, let's just add a sphinx directive to make this
automatic.
Change-Id: I05b2a65b52809d249bfb299164d624f6de5bff02
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>