mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-09-02 06:55:16 +00:00
Code Issues Releases Wiki Activity

[#1169] updated release checklist gitlab issue template

Browse Source
This commit is contained in:
Michal Nowikowski
2020-03-26 09:57:45 +01:00
parent 457111f9db
commit 38b5845f09
1 changed files with 84 additions and 146 deletions
Download Patch File Download Diff File Expand all files Collapse all files

230
.gitlab/issue_templates/release_checklist.md
View File

@@ -3,164 +3,102 @@ name: Release Checklist
about: Create a new issue using this checklist for each release about: Create a new issue using this checklist for each release
--- ---
# Kea Release Process # Kea Release Checklist
## Introduction
The Kea release process (for the base version of Kea and the hooks) is different to that of DHCP. At the moment, Kea has only one supported release at a time, so the process tries to ensure that any modifications needed for a release take place on the master branch, rather than on a version-specific one. The basic steps for a release are:
1) Announce a code freeze for the master branch that will last until actual tarball release This is thoroughly documented on https://wiki.isc.org/bin/view/QA/KeaReleaseProcess
2) Do all necessary changes to the master branch for the release
3) Create release tarball from master branch 1. [ ] Make this issue confidential :exclamation: :exclamation: :exclamation: :exclamation:
4) After sanity checks made by the QA and development teams, either we continue or we accept changes on master to fix issues if needed and go back to the previous step.
5) Create a release branch (for beta) or merge master to existing release branch (for final) and tag release on it. (???)
6) Sign and upload tarballs
7) Announce that freeze time on master branch is over.
8) Release tarballs are prepared by Jenkins job: https://jenkins.isc.org/job/kea-master-tarball-internal/. When given tarball is accepted for releasing it is pushed to repo.isc.org using Jenkins job: https://jenkins.isc.org/job/kea-release-upload-internal/
## Pre-Release Preparation ## Pre-Release Preparation
Some of those checks and updates can be made before actual freeze, but it's reasonable to announce freeze now! Some of those checks and updates can be made before actual freeze.
- [ ] 1. Check Jenkins results: 1. Check Jenkins results:
* Number of unit tests and system tests failing 1. [ ] Check Jenkins jobs if looks ok (distcheck, etc)
* Is there a change in system tests pass rate? *Notify the development team of the overall Jenkins status 1. [ ] Check Jenkins Tests Report: https://jenkins.isc.org/job/kea-1.7/job/jenkins-tests-report/
* Look into tarball check report " Kea Build Checks" on last tarball build and check if there is nothing suspicious (add/removed files, etc), verify that with developers: 1. [ ] Check tarball check report: https://jenkins.isc.org/job/kea-1.7/job/tarball-internal/Kea_20Build_20Checks/
* Compare current release package with code in repository 1. [ ] Check Perflab for drops in performance there (https://perflab.isc.org/)
* Compare current release package with previous release package 1. Check versioning, ask the development team if
- the library versions are being updated
- the HOOKS_VERSION is being updated;
- [ ] create an issue for that for developers in Gitlab
1. [ ] Create Release Notes on Kea GitLab wiki and notify @tomek about that. It should created under "release notes" folder, like this one: https://gitlab.isc.org/isc-projects/kea/wikis/release%20notes/Release-notes-1.5-final
1. [ ] Run https://jenkins.isc.org/job/kea-1.7/job/release-pkgs-upload-internal/ and https://jenkins.isc.org/job/kea-1.7/job/release-pkgs-check-internal/ for testing repos to check if they work correctly.
- [ ] 2. Is the distcheck passing on kea and kea+premium (https://jenkins.isc.org/job/kea-master-distcheck/)? The following steps may involve changing files in the repository.
* Highlight any issues that require fixing.
- [ ] 3. Check perflab if there is no critical errors there (https://perflab.isc.org/) 1. [ ] Create a Kea issue for code changes that will be made due to the following checks
- [ ] 4. Make sure that there is no pending ticket to merge! (Use GitLab https://gitlab.isc.org/isc-projects/kea/merge_requests and https://gitlab.isc.org/isc-private/kea-premium/merge_requests or contact the development team). 1. Check User's Guide sections:
- [ ] 5. Check the Known Issues list, is there something that suppose to be fixed before release and was omitted? 1. Chapter 1. Introduction
- [ ] 6. Check versioning: 1. [ ] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
* Ask the development team if the library versions are being updated (there is a step to check it later). 1. [ ] Did we add any additional 3rd party software? Update if needed
* Ask the development team if the HOOKS_VERSION is being updated. 1. [ ] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
- [ ] 7. Create Release Notes on Kea GitLab wiki using standard template, update all dates and versions. This wiki page should created under "release notes" folder, like this one: release-notes-1.5-final 1. Chapter 2. Quick Start
- [ ] 8. Check if there is a Release Checklist ready. If not, create new one using this template (page could have been created, check Releases section at the bottom of this page) 1. [ ] Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
1. Chapter 3. Installation
1. [ ] Check installation hierarchy
1. [ ] Check and update Building Requirements
1. [ ] Check configure options against what ./configure -h says
1. [ ] Check ChangeLog entries in Kea main and premium: spelling, trailing whatspaces, etc.
1. [ ] Check AUTHORS, INSTALL, README files in Kea main and premium.
- AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
1. [ ] Update information in sources about copyright dates, new version, etc, script: https://gitlab.isc.org/isc-private/qa-dhcp/blob/master/kea/build/prepare_kea_release.sh
1. [ ] Regenerate parsers using docs.isc.org, script: https://gitlab.isc.org/isc-private/qa-dhcp/blob/master/kea/build/regen-parsers.sh.
The following steps may involve changing files in the repository. If any files will be updated, create a Kea ticket for them and make the changes on a separate branch.
- [ ] 1. Check User's Guide sections:
* Chapter 1. Introduction
- On what platforms we are running tests using Jenkins? Update Supported Platforms
- Did we add any additional 3rd party software? Update if needed
- Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
* Chapter 2. Quick Start
- Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
* Chapter 3. Installation
- Check installation hierarchy
- Check and update Building Requirements
- Check configure options against what ./configure -h says
- [ ] 2. Check !ChangeLog entries in Kea main and premium:
* Spelling, missing numbers, trailing whatspaces? (some of that is checked in every build of tarball-internal Jenkins job)
* Update Release Notes with !ChangeLog entries
- [ ] 3. Check AUTHORS, INSTALL, README files in Kea main and premium.
- [ ] 4. Update information in sources about copyright dates, new version, etc. This is done manually using script https://gitlab.isc.org/isc-private/qa-dhcp/blob/master/kea/build/prepare_kea_release.sh
- [ ] 5. Regenerate parsers using docs.isc.org:
* download kea repo
```
cd kea; autoreconf -fi; ./configure --with-log4cplus=/home/wlodek/log4cplus --enable-generate-parser (log4cplus in /home/wlodek should be available for everyone, if not - download your own)
export PATH=/home/fdupont/bin:$PATH
cd ~/kea/src/bin/dhcp4; touch *.yy; make parser
cd ~/kea/src/bin/dhcp6; touch *.yy; make parser
cd ~/kea/src/bin/d2; touch *.yy; make parser
cd ~/kea/src/bin/agent; touch *.yy; make parser
cd ~/kea/src/bin/netconf/; touch *.yy; make parser
cd ~/kea/src/lib/eval; touch *.yy; make parser
```
TODO: we should regenerate all of them or just the one that been modified?
If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the branch to master. If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the branch to master.
## Build selection and upload package ## Build selection and upload package
That is the last moment to freeze code! That is the last moment to freeze code!
- [ ] 1. Update release version in configure.ac and remove -git suffix, and commit the change on master. From that moment all tarball builds can be officially released. 1. [ ] Go to tarball-internal Jenkins job and pick last tarball built - it will be a release candidate.
- [ ] 2. Go to tarball-internal Jenkins job and pick last tarball build - it will be a release candidate. 1. [ ] Check tarball before requesting sanity checks from dev team
- [ ] 3. Tarball checks before requesting sanity checks from dev team 1. Download tarballs from picked jenkins build
* Download tarballs from picked jenkins build 1. Check sizes - is new package reasonable?
Untar packages: 1. Check installation tree, compare it with previous release
* Check sizes - is new package reasonable? 1. Check installed lib versions
* Check installation tree, compare it with previous release 1. which were updated? (save results)
* Check installed lib versions 1. any of the lib from current release has lower number then corresponding lib from previous release? (!)
* which were updated? (save results) 1. Uninstall Kea, check what left (there should be just configuration files)
* any of the lib from current release has lower number then corresponding lib from previous release? (!) 1. Check if all of installed binaries has man page
* Uninstall Kea, check what left (there should be just configuration files) 1. if not, is it in the tarball?
* Check if all of installed binaries has man page 1. are man page up-to-date?
* if not, is it in the tarball? 1. Check if documentation is properly formatted, has correct versions and dates.
* are man page up-to-date? 1. it's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid
* Check if documentation is properly formatted, has correct versions and dates. 1. [ ] If all seems to be ok then upload tarballs to repo.isc.org
* it's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid 1. Go to release-upload Jenkins job
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick:
1. rc1 if this is the first selected build for release, it will push selected tarballs to repo.isc.org, to folder suffixed with indicated rc#
1. next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in error)
1. final if the last rc number was ok, this will push selected tarbal to repo.isc.org, to folder with no suffixes
1. [ ] If none of the results force you to fix and rebuild package, send sanity checks request
- [ ] 4. If all seems to be ok then upload tarballs to repo.isc.org ## Sanity Checks
* Go to release-upload Jenkins job
* Click "Build with Parameters"
* In field "Tarball" select picked tarball build
* In field "Release_Candidate" pick:
* rc1 if this is the first selected build for release, it will push selected tarballs to repo.isc.org, to folder suffixed with indicated rc#
* next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in error)
* final if the last rc number was ok, this will push selected tarbal to repo.isc.org, to folder with no suffixes
- [ ] 5. If none of the results force you to fix and rebuild package, send sanity check request by an email to dhcp-team@isc.org and qa@isc.org with indicating paths with tarballs on repo.isc.org asking for sanity checks 1. [ ] Create Sanity Checks announcement, put there:
- a link to sanity checks steps: https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, "4. Sanity Checks" chapter
- a link to an issue created in next step
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
1. [ ] Create a GitLab issue for sanity checks, put there the announcement
1. [ ] Send the announcement to dhcp-team@isc.org
## Sanity checks proposals: ## Releasing Tarballs
- [ ] 1. Check documentation: 1. [ ] Update Release Notes with ChangeLog entries
* users guide: 1. [ ] Upload final tarballs to repo.isc.org
- dates, versions, installation instructions both for kea and premium, formatting 1. Go to release-upload Jenkins job again
- if you have time - read as much as you can. 1. Click "Build with Parameters"
* man pages: 1. In field "Tarball" select picked tarball build
- dates, versions, is it up-to-date? or usage changed between releases? 1. In field "Release_Candidate" pick final
- does every binary has it's own .8 page? 1. [ ] When the upload is completed then copy SHA checksums from the log and write an email to signers@isc.org requesting signatures
- [ ] 2. Check tarball content: of final tarballs on repo.isc.org indicating release folders. Attach SHA checksums to the request.
* compare tarball against repo (does some of the not included files should actually be included?) 1. [ ] Upload final RPM & DEB packages to cloudsmith.io
* does premium tarballs include correct hooks? (any missing files?) 1. Go to https://jenkins.isc.org/job/kea-1.7/job/pkg/
- [ ] 3. compile: 1. Pick the build for selected tarball in previous steps
* configure warnings? 1. Go to https://jenkins.isc.org/job/kea-1.7/job/release-pkgs-upload-internal/
* build warnings? 1. Click "Build with Parameters" link
- [ ] 4. run unit tests with various db backends, install (check tree), uninstall (check tree) 1. Pick your selected pkg build in Packages field, and select "prodcion" in Repository_Type field and click Build button.
- [ ] 5. Check example configurations 1. When it finishes run check: https://jenkins.isc.org/job/kea-1.7/job/release-pkgs-check-internal/
- [ ] 6. Check release notes (not included in tarball) 1. [ ] Create git tags `Kea-1.x.y` in Kea main and premium repositories
- [ ] 7. Check AUTHORS, INSTALL, COPYING, README files 1. [ ] Trigger rebuilding docs on https://readthedocs.org/projects/kea/builds
- [ ] 8. Check db update scripts:
* tarball inlcude the last one? (compare with repo)
## Releasing tarballs:
- [ ] 1. Write an email to signers@isc.org requesting signatures of final tarballs on repo.isc.org indicating release folders. - Attach SHA256 checksums from tarball-internal logs.
- [ ] 2. Make release branch (e.g. v1_5_0 one branch for beta and final, with tags for both releases)
- [ ] 3. Upload Release Notes to repo.isc.org
- [ ] 4. When release packages are signed then upload them from repo.isc.org to ftp:
* make-available --public --symlink=cur /data/shared/sweng/kea/releases/1.4.0-beta
* make-available --private /data/shared/sweng/kea/releases/premium-1.4.0-beta/
* make-available --private /data/shared/sweng/kea/releases/subscription-1.4.0-beta/
- [ ] 5. Contact support or marketing to upload packages to www.isc.org/downloads
- [ ] 6. Contact marketing to upload premium packages to 'products' in web store
- [ ] 7. Contact support to deliver premium and subscriber-only hooks to Kea support subscribers
- [ ] 8. For final release - Release Notes should contain changlogs since previous stable release (beta +final)
- [ ] 9. Modify Release Notes to Announcement
- fold -sw 73 Kea140betaReleaseNotes.txt > Announcement
- change header
- change ftp links to ww.isc.org/downloads
- send it to yourself to check if it's ok
- [ ] 10. Prepare article on kb.isc.org
- change editing mode to HTML, copy release notes between <pre></pre>
- ask support to publish this document
- [ ] 11. Send announcements on:
* kea-users@lists.isc.org
* kea-announce@lists.isc.org
* dhcp-announce@lists.isc.org
- [ ] 12. Notify marketing to announce via social media, publish any blog post that is planned
* publish any blog post that is planned
* Update kea.isc.org
* Update Wikipedia page release info
* Add new hooks to downloadable products (if applies)
* Update subscription data sheet with any new hook (if applies)
* Inform sales about what the release may mean to them
- [ ] 13. Check KnownIssues list on kea.isc.org https://kea.isc.org/wiki/KeaKnownIssues
- ssh kea.isc.org /var/www/kea-docs
- [ ] 14. update page: https://wiki.isc.org/bin/view/Main/KeaReleaseDates
- [ ] 15. update page: https://wiki.isc.org/bin/view/Main/EngineeringReleaseSchedule