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: Ia14576c167c722b71ef96a6f5cabecb7028af7b7
This is a procedural review to tag a final release for each deliverables
It's possible that the release isn't needed (for example if there are no code
changes since 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.
Don't tag DOA as there hasn't been any functional code change since
3.6.1
Change-Id: Ic460372fd8426b998d69690f4f5e737726c9f91d
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>
manchandavishal