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: Iea97c3534df7d73d2666c4765dfc50eb4c99f306
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
Some projects have updated their release-type for horizon
plugins in queens, but a similar change has not been done
in pike. Rather than waiting for their first stable release
request to fail, adding these changes to those deliverables
to account for these changes.
Change-Id: Ifd51d3dd1d04b1bb11d311fc46f6faf642d432c4
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