Pike branch for networking projects has many issues in the last cycles
and few actual backports on them.
Some projects' (bgpvpn and bagpipe) pike is already EOL-d, so it is
time to do the same for the remaining projects also as for the
announcement mail (see [1]) there was no answer and desire to keep the
pike branch open.
[1]: http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028126.html
Change-Id: Iad31204a859d87009640b79b4eb59efe81ad18b5
This is a procedural review to transition pike into extended
maintenance by creating the pike-em tag.
It's possible that the release isn't needed (for example if
there are no code changes sine the previous release, sadly
that's non-trivial to detect en masse).
If you are the PTL or release liaison for this team please +1
this review if it is ready or -1 and take over the review to
correct mistakes.
Change-Id: I1b88befeafc0a954fb99add3a6fbf404916ecfdb
This is a procedural review to tag a final release for each
deliverable.
It's possible that the release isn't needed (for example if there are
no code changes sine the previous release, sadly that's non-trivial to
detect en masse.
If you are the PTL or release liaison for this team please +1 this
review if it is ready or -1 and take over the review to correct
mistakes.
Change-Id: I4a12cf4068b2c13a1ef448dfc1083f52f38baaf3
We've been warning that these are deprecated for awhile now, and
we now have enforcement in place to make sure no new highlights
are added.
We also have some automation that rewrites the deliverable files
but does not always do a great job, resulting in poorly formatted
text that causes warnings in the validation job.
Since many folks new to the release process, and some that have
done it for awhile, look at existing files to see what to do for
new releases, they do assume highlights should be used and end up
adding them to their deliverable file. Since most of these also
do not know to run local validatation, this results in gate
resources being used to just now be rejected with the current
checks.
To help prevent this from happening, and to get rid of the warning
messages from poor reformatting, this just removes highlights
from the last few releases.
Change-Id: Ie0b0e241c38f84bbc7b1ef5b09e97dc8ec466b39
In current stable Pike branch there are:
- 8 bugfixes for neutron
- 2 bugfixes for neutron-lbaas
- other projects do not contain any bugfixes
Change-Id: I4a59a8467af2ebffe9dc3e8da4c35d522721c014
The final release of Pike had multiple regressions in DVR code as well
as in SR-IOV logic. It also lacked several fixes for better API
compatibility for the new Pecan framework. This release should fix
those.
It includes neutron and neutron-fwaas only. -dynamic-routing didn't have
any new patches.
Change-Id: I67b33a5fb7fe6c667c52b6112bb54d70976855d1
The Pike release script had a typo that caused the release emails to
have incorrect diff output.
This patch causes the validate test to catch more typos for releases
and branches. It also fixes the typos in the existing deliverables
files so they will pass future validation.
Change-Id: If173ba0b3d8c427f0bf5f3e4972dd0848459c951
Following the release process[1], all projects that are publishing
release notes have the notes link included in their deliverable
file.
Extra changes (like true -> yes) are included due to the use of
edit-deliverables YAML linter.
Change-Id: Ibd63f0f8bf1d406039c0196560768beb9f6650ce
We no longer use the send-announcements-to field for anything.
Change-Id: Iec0b11ced00ea06ac459ad544b1cb2db20d2892d
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Create the deliverable files for Pike based on the ones that were
released during Ocata. Leave out release and branch information, since
that will be filled in for the first release.
Change-Id: Idf3e9a3eadba86038f6b69527a109a0cad79bf8c
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
elajkat