This new section in our Cycle Information email template emphasizes
how important it is to get PTL and release liaison reviews as soon as
possible, in order to keep the schedule and its deadlines.
Change-Id: I8706b6fff5a72cf776d06b5205399b5d118a37d4
The process autorelease command for milestone-1 was missing a backward
slash in the command in (2) after the --type library
Now, the command has the right forward slash that looks like this:
--type library \
Change-Id: I852497033ff15d85fda50c61f4ec60bd2e4cc881
Signed-off-by: Armstrong Foundjem <foundjem@ieee.org>
Client libraries (and other libraries strongly tied to another
deliverable) should generally follow their parent deliverable release
model, even if they did not have a lot of activity themselves.
Rephrase 'evaluate' task to only consider non-client libraries for
model change.
Change-Id: Ifbe2889ada78cf52c56e6d261f47883300033f4d
R-3 week's task for unreleased cycle-with-intermediary deliverables
contains also '--type tempest-plugin' however there is a dedicated task
for them in R-2. This patch keeps the dedicated task and removes the
redundant one from R-3.
This patch also adds a note with some task details to the modified task
to make it more clear.
Change-Id: I41906a133ff8925a5ed08b4bc52229e279651acb
Cycle Highligts original deadline was the same as Feature Freeze date.
This caused extra burden to PTLs as while they were reviewing the last
patches at FF, they also needed to write the highligts at the same
time.
This patch postpones one week the Cycle Highlights task so that the
deadline indicates more that is needed AFTER the projects feature
freeze, but still gives the time to Marketing team to process the
cycle highligts.
Note that the best is to collect the Cycle Highlights in advance as
much and as soon as possible, because for Marketing team perspective
having an incomplete list of highlights is better than waiting until a
complete list can be constructed.
Change-Id: Ibe8f0faebcce480bac79a789fb689112038b48c8
As some deliverables don't really fit the cycle-with-rc model but
released only once per cycle, the process would still suggest the model
change. This patch adds a note that for such cases the model change
is not a must.
Change-Id: I3ae583dab2df800a40fbca449fd2e6f08425bd5a
Branching the devstack-plugin-* is missing since 2 cycles
(victoria/wallaby), these changes add a related task at R-3 to
ensure to not miss them anymore.
Some tasks of R-2 aren't crystal clear about the expected state of the
series branching.
Some commands are more or less duplicated and inefficient.
Indeed, the QA PTL should be "reminded" once branching is done but the
checks are made after. Also we previous version of this doc was using
two commands who are more or less similar, however, one of them doesn't
caught the `cycle-with-intermediary` deliverables and also doesn't ignore
trailing projects (branching isn't mandatory at this point for them).
These changes remove the duplicated commands and prefer to use the
better one.
These changes reorder steps to "remind" people at the right time and when
all prerequisite are there.
Change-Id: I765e74b15e1f8fc6e45fb90662d04464faf17640
Previously the tempest plugins were driven by the legacy
`cycle-automatic` model. However this model have been abandoned.
The cycle-automatic release model is now better described by the
`cycle-with-intermediary` model combined with `stable-branch-type: none`
The `cycle-automatic` model was used by specific technical deliverables
that needed to be automatically released once at the end of a cycle.
the tempest-plugin are branchless and `cycle-with-intermediary`
however our process doesn't handle them at the end of the cycle
like did the `cycle-automatic`.
These changes clarifying that point.
Change-Id: I6b3619a44d0aea1fa4852e650cbafcb08c853353
Some traiing projects follow the cycle-with-rc model however our doc
and our tools doesn't differentiate them during RC1. These project
doesn't have to be released during RC1. These changes adapt our process
accordingly.
Change-Id: I44040bc040f19a75c468d385395323fe0a1f459a
These changes aim to standardize the gerrit topic to use with on our patches.
This:
- will allow us to better retrieve the history from previous series;
- could allow us to generate some statistic and monitoring from series
to series to allow us to get a better big picture of things are.
I already defined this point the potential process/tools changes for Xena.
https://etherpad.opendev.org/p/xena-ptg-os-relmgt
Maintenance mode is becoming more and more prominent, a little standardization
can't hurt.
Change-Id: Ib7ea93fce7e618a2dbba8dd9f4153897bdfee22a
The process was a bit unclear on what to do with libraries that
did not have changes / releases in the current cycle but still
should not be transitioned to "independent" (like client libraries
and other libraries that should stay attached to their main
deliverables release model).
Change-Id: I4ee317c71f90d2f502d3852d8499752dc39177eb
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
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
These sentences seems wrong as we proposed many time to move release
models in the middle of the cycle.
Change-Id: I71cb18682761775894bf4f03ddc68f5b66335335
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