VPP CommitterTasks PullThrottleBranch

Contents

• 1 Pulling a VPP Throttle Branch
• 2 Marking the auto-generated release notes for later use
• 3 Historical Recipes

VPP RC1 pre-Milestone Tasklist

1. At least a week prior to the RC1 date, email a reminder to email about VPP RC1 Milestone. See an example email or another example email.

2. To be done before RC1:

   a. Verify that packagecloud.io repository fdio/YYMM (as corresponding to the branch stable/YYMM that is being created) exists and follow up with Dave Wallace to ensure it is created and has "lf-fdio" added as a collaborator.

   b. Prepare "first commit of rc0 of next release" commit on master branch so it is ready for merge + tagging at the time of the RC1.

3. Resend reminder about (1) a day or two prior to the RC1 date.

Pulling a VPP Throttle Branch

NOTE: Steps 4 and 5 can be done any time prior to RC1 branch day. At the very least, discuss the requirements with the individuals ahead of time to set the correct expectations.

4. Request Dave Wallace or Vanessa Valderamma create the packagecloud.io repos.

5. (since 22.02) On master branch, edit docs/aboutvpp/releasenotes/index.rst and remove the oldest version designator. Add this same version designator at the top of the docs/aboutvpp/releasenotes/past.rst file. This will be the commit that the next release -rc0 tag is placed on.

   Examples:

    <https://gerrit.fd.io/r/c/vpp/+/34967>
   

6. Lay down a tag for the next release RC0 (e.g. 1804-rc0) on master, using the hash of the above commit as an explicit argument for tagging.

   a. Verify that the tag shows up by looking for it at https://git.fd.io/vpp/log/ - it usually takes a few minutes.

   b. Remerge the last merged patch on master - you can see the "to be" version in the build logs for the merge jobs.

   c. When the remerge of the last patch on master is complete, go look for package with the correct versions at packagecloud.io/fdio/master

   d. Follow instructions on Installing VPP binaries from packages and verify that packages with the new versions are installed on packagecloud.io

There may be existing patches from others waiting to be merged on master - then instead of a remerge of the patch from step (6), if that patch is being merged, it can be used for sanity check instead of patch from step (6).

7. Create a new branch stable/YYMM (example: stable/1801) in the Gerrit web UI and specify the hash of the commit JUST BEFORE the one you merged in step 6.

   a. https://gerrit.fd.io/r/#/admin/projects/vpp,branches

8. On the new stable/YYMM branch (example: stable/1801) prepare a commit which updates the .gitreview to reflect the correct branch. (You will need a "git pull" in your local repo to see the ref for the newly created branch).

   a. Examples:

    <https://gerrit.fd.io/r/c/vpp/+/34968>
    <https://gerrit.fd.io/r/#/c/1157/1/.gitreview>
    <https://gerrit.fd.io/r/#/c/9937/>
   

   b. Merge patch onto the new stable branch

NOTE: Verify that this patch is in fact on the new stable branch, and not on master!

9. Lay down a tag (v18.01-rc1) on stable/1801 at the point of the patch you just merged.

NOTE: If the verification steps in 10 & 11 don't happen by the end of the day, it is best to send an email re-opening master to commits.

10. Verify that the packagecloud.io repos have packages with the correct version and are working

    a. Remerge the patch from step 8 after you push the tag (you can verify the to-be version of artifacts in the beginning of the VPP build log messages)

    b. When the remerge from step 9 is complete, verify that the correct package versions have been uploaded onto the packagecloud.io/fdio/XXYY repository - if the job succeeded, the packages typically will be there. You can verify by visiting the packagecloud.io web interface and checking there.

    c. Verify that the packages for the supported OSes are installable from the packagecloud.io/fdio/XXYY repo

    d. Update the Installing VPP Binaries from Packages Wiki page with instructions for the new branch, and test that you can install packages from packagecloud.io

    e. Create a gerrit change that updates the "VPP stable release Branch Repo" section to reference this release when installing the latest stable branch vpp image from packagecloud.io. Note: this has the intended side effect of generating the first set of docs for the next release when it is merged (based on the new RC0 tag on the master branch).

11. Send the all-clear message. Example.

Amend as necessary with any caveats; for example the 1804 RC1 milestone opened master and stable on different days while minor issues were resolved.

Marking the auto-generated release notes for later use

To facilitate the automated creation of the release notes, put a vXX.YY-rc1 tag onto https://github.com/vpp-dev/vpp-release-notes and push it there. This will allow to easily find the correct version of the release notes, as after the VPP -rc0 tag for the new release is pushed, they will be overwritten the next day!