VPP/CommitterTasks/PullThrottleBranch
VPP RC1 pre-Milestone Tasklist
1. At least a week prior to the RC1 date, email a reminder to vpp-dev@lists.fd.io about VPP RC1 Milestone. See an example email or another example email.
2. To be done before RC1:
- a. Follow-up that ci-management change below is merged
- b. Verify that packagecloud.io repository fdio/YYMM (as corresponding to the branch stable/YYMM that is being created) exists and follow up with Ed Warnicke to ensure it is created and has "lf-fdio" added as a collaborator.
- c. 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 3 and 4 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.
3. nexus - no longer needed.
4. Request Ed Warnicke create the package cloud repos. Send and email to Ed Warnicke (eaw@cisco.com and/or hagbard@gmail.com) reminding him to create the package cloud repositories for the new release, and have lf-fdio as a collaborator. Since 21.01RC1 the verify/merge jobs do not require the packages to be present in the deb repos.
5. Jenkins: (can be done and merged some days before the date of pulling the branch) - In the ci-management Git repo, edit jjb/vpp/vpp.yaml:
- a. https://git.fd.io/ci-management/tree/jjb/vpp/vpp.yaml#n49
- add a new 'stream' for your new YYMM. Example for stable/1801:
- '1801':
branch: 'stable/1801’'
repo-stream-part: 'stable.1801'
- b. https://git.fd.io/ci-management/tree/jjb/vpp/vpp.yaml#n87
- likewise add a new stream here. Exactly the same idea as the previous step.
- c. Example: https://gerrit.fd.io/r/9934/
- d. Similarly, edit
jjb/vpp/docs.yaml- add a new 'stream' for your new YYMM. Example for stable/1904:
- '1904':
branch: 'stable/1904’'
repo-stream-part: 'stable.1904'
- e. Example: https://gerrit.fd.io/r/#/c/18982/
6. (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:
6. (before 22.02) On master branch, edit vpp/RELEASE.md and add a placeholder for the next release and merge the patch on master and edit vpp/doxygen/test_framework_doc.md and add a new link to the next release's test framework documentation. This will be the commit that the next release -rc0 tag is placed on.
- Examples:
7. 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 VPP/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).
8. 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.
9. 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).
- 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!
10. 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 11 & 12 don't happen by the end of the day, it is best to send an email re-opening master to commits.
11. Verify that the packagecloud.io repos have packages with the correct version and are working
- a. Remerge the patch from step 9 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
12. Send the all-clear message. Example.
13. If the Jira steps from VPP/CommitterTasks/ApiFreeze#Jira_versions didn't happen yet, do them now.
Amend as necessary with any caveats; for example the 1804 RC1 milestone opened master and stable on different days while minor issues were resolved.
