The official-openstack-repo-jobs template should be kept during
repository retirement process to sync updates to GitHub mirrors.
Change-Id: Ib1fdc4c805a62d04f8cdbcedd5fcafd7ab69a79e
Add a step to remove a deliverable's yaml file from the
openstack/releases repository when a project is deprecated.
Change-Id: I84490c186f2d39dc2ab01fbbc63a4bb880e24d93
In TC meeting[1], we discussed about how to
notify community to add for the extra AC. In
every election, we need to call for adding the
extra-AC. Adding this a one of the task for PTL
so that they remind to propose the extra AC of
their project.
[1] https://meetings.opendev.org/meetings/tc/2023/tc.2023-09-05-18.01.log.html
Change-Id: I9cd2ab4724dad5a30f551fe3a728b2a06f775cc0
The aim of this patch is:
- make clear what the TC suggests doing
- make clear why the TC thinks it should be done this way
- give a helpful example of how to do it
Change-Id: I90b7600866d0d99b5cfccecb2bda9f2505ef4b27
When we deprecate the branchless repo (for example, tempest
or any other tests repo), sometime they need to support the
other deliverables stable branches. In that case we cannot
remove those branchless repo master branch content. We can just
update the README.rst file to reflect the deprecation and postponed
the master branch content removal until all deps are either retired
or EOL.
One such case is TripleO test repo
- https://review.opendev.org/c/openstack/governance/+/877132/2/reference/projects.yaml#2846
Change-Id: Ie8cbd77bb4fa2914f42e2c5cf6cd6fdc2d116bd3
Some steps are not clear enough and requires to do extra research or
educated guesses on what is exactly meant in a specific step. This patch
aims to clerify required steps - what repository and what files should be
changed to get project deprecated. Also some generic cleanup made.
Change-Id: I8a749acbd2b26327114ef76d4e79c06c3ed5b8c6
We at upstream community cannot commit to the maintenance of
Extended Maintenance branches and its testing. Idea behind the
Extended Maintenance is to keep them open as long as we can and
anyone backporting the fixes take care of tetsing fix or so.
Change-Id: Ide5d13139493737e5ce948b62cd1da9aad7022c7
While renaming or retiring repository, we usually forget to update the
openstack-map and zuul jobs definition. To remind to do those, let's
explicitly add these steps in repository rename/retire process.
Change-Id: I8fd68f1ef4b4b1307d9f5fa3023f0a7544186268
In repo retirement process, we need to wait for
governance patch to get TC agreement as well as to check
the proper retirement which need repo content removal first
to check the proper retirement. But as we refer to the OpenDev
manual for 3 steps together, this become confusing to mention the
right order. As per OpenStack process, those 3 steps need to be in
different order.
We have note about those but still it may confuse people to know
the right order.
I am extracting the each step explictly and what patch they need
to depends-on.
Change-Id: Ie932b38c79eaa5947959c6f642c041acfdb87679
The Opensearch is storing most part of the Zuul CI job results
log files that can be useful for developers.
Change-Id: I3c79cdb7132c60595fe3fa5a46ec1c778db1d34e
In repo retirement steps, governance patch needs to wait until
repo content is removed. Fixing that step in doc.
Change-Id: I525f3c7ec21ddf64922cf785c3fdc15bc93f9f49
As discussed in the PTG, the tick deprecation example was too
aggressive in its requirements for notice, requiring more notice
time than we require today. This was not the intent, so this corrects
that to the expected timeline.
Change-Id: I241cf3723312b299697a44ee43cc8aeadfadadd7
Per recent discussions, this attempts to provide some general
guidance about responsible use of rechecks that we can link to when
"encouraging" people to exhibit the desired behavior.
Change-Id: Iadfc32f79423b54e5933788686791c42c8d616fd
Sometime it is confusing whether to merge the
repo retirement/deprecation in governance and then
start the code/infra cleanup or other way around.
Usually all code/infra cleanup patches check if
there is patch submitted in governance or not.
If there is objection by TC or by any reasonTC decided
not to approve the repo retirement/deprecation then code/infra
cleanup including the project rename revert will be very costly.
To make it the process clear and in right sequence, updating the
document to merge the governance patch first and then start the
other steps.
Change-Id: I5c911f9dde8e4244156ad79898299dc3f0a11460
We have new directory technical-guides which include
the new guidlines unified limits. We can move the existing
file technical-guidance.rst also under the same dir to
avoid any confusion.
Change-Id: Ibe9facc4518b1f1317579373b40a5e63f89d2240
This moves the guidelines of how feature deprecation should be handled
from the definition of assert:follows-standard-deprecation tag to
a document here. It reformats the verbiage therein to describe the
procedures as a guideline instead of adherence to an asserted tag. It
also modifies the procedures to be in line with the newly-adopted
TC resolution to modify the release cadence with tick and tock
designations which impact the timing of deprecations and feature
removals.
Change-Id: I9e6b252e81f893e0007c5b917328b73765d072c7
The command seems to be out of date and there is a tox
target that already takes care of it with an up to date command
so let's instruct developers to use that.
Change-Id: I0848248e21dfc23466310ff1996f898f270dd12c
During Xena Virtual PTG on the Technical Committee session there was a
discussion, that the 'Unmaintained' phase is not really clear for the
community and just creates confusion. The decision was to simply remove
this phase as the process is more clear and works well without it.
Change-Id: I9589cbdd74d83d23ad42ce6724e3b8e4cc56c44d
We have a new tempest publish-to-pypi-stable-only now which is
used for the deprecated repo which still support stable branches.
This commit document it in project-team-guide.
Ref: https://review.opendev.org/c/openstack/project-config/+/800558
Change-Id: If4c73fe6a32f9e2a4f9841ab67aab05f7d76f6d3
From the release team point of view we need to ensure that deliverables are
well tagged as retired to ensure that our machinery will work as
expected all along the series life cycle.
Here is an example of experienced problem with your validation:
https://review.opendev.org/c/openstack/releases/+/792820/5..6
Change-Id: I6cb59e7cc09bd6a8cda0ffe06ffcd896696aea86
As discussed during the migration from IRC freenode to
OFTC[1], TC encourage project team to hold their meeting
on their project channel.
Updating project team guide to reflect that.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022718.html
Change-Id: I6c58ff14402238b067a093e6d3974cbb5faf3b1b
UC has been merged into TC since June 2020, this
commit clarify it in project team guide docs and
remove the explicit reference of old committee.
Change-Id: I5c5fe7ec5121f6429ec7d198f88cb72d18204769