docs: Add Release process docs #56

jodh-intel · 2018-04-18T09:06:07Z

Add a document providing an overview of releases along with the
all-important release checklist.

Fixes #32.

Signed-off-by: James O. D. Hunt james.o.hunt@intel.com

jodh-intel · 2018-04-18T09:14:45Z

caveat emptor: this still has some issues:

ARM CI testing: what are we going to do about this?
The image generation strategy is still under discussion (kata-containers-image package osbuilder#78). This will decide whether we still need the "Assets upload" step in the checklist.
@jcvenegas - it would be good if the checklist could just say "run Carlos's magic tool to generate the release notes" :)
Automated installation testing (packaging CI) - CI for package testing ci#10
Documentation:
- There is no installation documentation (yet).
- There is no architecture document (yet).
I think it's safe and fair to leave it in the checklist for now though, since those docs must be created (and soon).

Also:

Now that the default hypervisor is vanilla qemu, should we still have a step to create a qemu-lite OBS package?

jcvenegas · 2018-04-18T14:33:03Z

@jodh-intel @erick0z packaging work now provides qemu vanilla and qemu-lite.
+1 for automation

At the moment the packaging tool will be generating the image and push it in the OBS serivice.
- We can change this in the future if needed.

jodh-intel · 2018-04-18T15:03:51Z

Hi @jcvenegas - thanks - I've added qemu-lite. Any other changes required at this stage? I'll update the checklist once kata-containers/packaging#1 appears ;)

Hi @klynnrif, @bergwolf, @kata-containers/architecture-committee - ptal.

jcvenegas · 2018-04-18T15:04:01Z

@jodh-intel others missing components are

Kernel: Today we still use the Clear Containers Kernel as part of the CI we need to have a configuration for Kata.
- The config is still under review from long time ago.
- We also need a documented process to update the kernel fork.
  \cc @devimc
  see : x86/defconfig: Add kata containers defconfig linux#5

jodh-intel · 2018-04-20T08:46:56Z

wdyt @egernst, @grahamwhaley, @erick0z?

grahamwhaley

This is really good to have!
Yes, we know it needs some more work, and it will be a bit of a 'living document' for a while, but still:
lgtm

grahamwhaley · 2018-04-20T10:31:44Z

Release-Checklist.md

@@ -0,0 +1,79 @@
+Change release process, instead create a release candidate we can test the HEAD what will be the last commit using new automated obs package generation we can generate and test commits based on HEAD.


This sentance doesn't read well - can we clean that up a bit?
Also, can we have a #TITLE here at the top as well (right now it just dives right on in..)

Some point to make clear are:

By sending a PR to update the VERSION file, we exercise the CI that tell us the project health.

OBS packages are created after we do tag the project repositories based in the tag we create.

Oh - that shouldn't even be there - zapped ;)

grahamwhaley · 2018-04-20T10:33:13Z

Release-Checklist.md

+
+- [ ] Get confirmation from metrics CI that performance is within acceptable limits.
+
+- [ ] Create an **annotated tag** for the new release version for the following repositories:


A hint/clue/link on how to make/ensure we make an annotated tag here would be nice.

And, do we need to define the tag/version format and rules?

We can add a link/ or describe that to ensure the process to tag is always the same use
kata-containers/packaging#16

Done (in the main doc to avoid bloating out the checklist).

grahamwhaley · 2018-04-20T10:34:55Z

Release-Checklist.md

+  - [ ] Ubuntu.
+
+- [ ] Check if any of the following need to be updated:
+ - [ ] Architecture document.


I think you need double spaces here? - they did not indent on my github md doc view window.

jcvenegas

Added more comments about the process.

jcvenegas · 2018-04-20T12:34:40Z

Release-Checklist.md

@@ -0,0 +1,79 @@
+Change release process, instead create a release candidate we can test the HEAD what will be the last commit using new automated obs package generation we can generate and test commits based on HEAD.


Some point to make clear are:

By sending a PR to update the VERSION file, we exercise the CI that tell us the project health.

OBS packages are created after we do tag the project repositories based in the tag we create.

jcvenegas · 2018-04-20T12:37:02Z

Release-Checklist.md

+
+  Note that the "phase" element of the project encoded in the version strings needs to match for all components. For example, when a `beta` is released, the version string for *all* components should show `beta`.
+
+- [ ] Ensure all CI tests pass **for all architectures**.


This ideally would be tested in the CI when we update versions file on a PR. We can add a section with the sub task that the CI should be able to done ( and add it if has not support today).

Sorry - not quite clear on what you're saying here. I agree that this should all be automated and it should just be a simple check on Jenkins/Travis to ensure all the CI builds pass (for all architectures).

Maybe that's all it should be for now and I could just raise an issue on @bergwolf say (hi! ;) to investigate the ARM/$other_arch CI support?

I think we should be specific on which architectures this will be done. Currently this isn't really a list AFAIU...

Well, since the CI currently only supports x86_64, do we want to just list that? @bergwolf - any thoughts?

jcvenegas · 2018-04-20T12:38:37Z

Release-Checklist.md

+
+- [ ] Get confirmation from metrics CI that performance is within acceptable limits.
+
+- [ ] Create an **annotated tag** for the new release version for the following repositories:


We can add a link/ or describe that to ensure the process to tag is always the same use
kata-containers/packaging#16

jcvenegas · 2018-04-20T12:40:52Z

Release-Checklist.md

+  - [ ] Add links to Installation instructions.
+  - [ ] Document any common vulnerabilities and exposures (CVEs) fixed with links to the CVE database.
+
+- [ ] Upload any assets to github:


Do we want to upload the kernel and images for the release or only be provided as part of the packages?

Yeah, I wasn't sure about this item. I'll remove it for now...

/cc @grahamwhaley, @erick0z, @egernst.

jcvenegas · 2018-04-20T13:09:17Z

We may want to have in all repos tags for issues:

Feature
Limitation
Bug

To at some point the release notes generator can know what are the new features for a release or what bugs were fixed. Also get an updated list of limitations.

jodh-intel · 2018-04-20T13:13:36Z

@bergwolf, @grahamwhaley, @klynnrif - branch updated.

jodh-intel · 2018-04-20T13:27:37Z

Yeah, I like the idea of automating more of the release notes. I think this could be handled without additional tagging though - we just need to make the script:

Extract the "Fixes #XXX" comments.
Query each issue.
Ensure the issue is "closed".
Ensure the issue is assigned to the same user as the commit author (maybe?)
See if the issue has any interesting tags, such as:
- limitation
- bug
- feature
- security

egernst · 2018-04-20T16:17:34Z

@jodh-intel this looks good. I wonder if we should update the section about which architectures are tested in our CI to be specific.

klynnrif

Scrubbed for grammar, structure, and flow. Thanks!

klynnrif · 2018-04-20T23:49:49Z

Release-Checklist.md

+It should be pasted directly into a github issue and each item checked off as it is completed.
+
+- [ ] Raise PRs to update the `VERSION` file in the following repositories:
+   - [ ] [agent][agent].


Lines 8-12 suggest removing the period after each line because the bulleted list items are not complete sentences.

klynnrif · 2018-04-20T23:51:20Z

Release-Checklist.md

+- [ ] Get confirmation from metrics CI that performance is within acceptable limits.
+
+- [ ] Create a **signed and annotated tag** for the new release version for the following repositories:
+   - [ ] [agent][agent].


Lines 21-25 - same comment regarding removing the period after each bullet item.

klynnrif · 2018-04-20T23:52:40Z

Release-Checklist.md

+   This is required by `git describe`.
+
+- [ ] Generate OBS packages based on `HEAD`:
+   - [ ] [agent][agent].


Lines 30 - 38 - same note regarding removing the period after each bullet list item.

klynnrif · 2018-04-20T23:53:43Z

Release-Checklist.md

+   - [ ] [shim][shim].
+   - [ ] [throttler][throttler].
+
+- [ ] Installation tests (must be done for major releases)


Line 40 - add a colon at the end: Installation tests (must be done for major releases):

klynnrif · 2018-04-20T23:58:21Z

Release-Checklist.md

+   - [ ] [throttler][throttler].
+
+- [ ] Installation tests (must be done for major releases)
+  - [ ] Centos.


Lines 41 - 43 - same note regarding removing the period after each bullet item.

klynnrif · 2018-04-21T00:06:13Z

Release-Checklist.md

+
+- [ ] Update public IRC channel with a link to the latest release.
+
+- [ ] Arrange for release to be communicated via other social media channels.


Suggested rewrite to stay active: Arrange communication of the release through other social media channels.

klynnrif · 2018-04-21T00:10:10Z

Releases.md

+
+For examples: `1.0.0`, `1.0.0-rc.5`, and `99.123.77+foo.bar.baz.5`.
+
+Semantic versioning is used since the version number is able to convey clear information about how a new version relates to the previous version. It can also provide assurances to allow users to know for example when they must upgrade compared with when they may wish to upgrade:


Suggested rewrite of second sentence: ... For example, semantic versioning can also provide assurances to allow users to know when they must upgrade compared with when they might want to upgrade:

klynnrif · 2018-04-21T00:11:42Z

Releases.md

+- When `PATCH` increases, the new release contains important **security fixes**
+  and an upgrade is recommended.
+
+  The patch field can contain extra details after the number. Dashes denote pre-release versions. `1.0.0-rc.5` in the example denotes the fifth release candidate for release `1.0.0`. Plus signs denote other details. In our example, `+foo.bar.baz.5` is additional information regarding release `99.123.77` in the example above.


Replace "above" with "previous" at the end of line 27: In our example, +foo.bar.baz.5 is additional information regarding release 99.123.77 in the previous example.

klynnrif · 2018-04-21T00:14:33Z

Releases.md

+$ git tag -as $tag
+```
+
+The tag name (`$tag` in the example above) must conform to the [versioning](#versioning) an example being `1.0.0-rc2`.


The tag name ($tag in the previous example) must conform to the versioning (e.g. 1.0.0-rc2).

klynnrif · 2018-04-21T00:16:19Z

Releases.md

+
+## Release process
+
+The Release Owner must follow the following process, which is designed to ensure clarity, quality, stability and auditability of each release:


Add the series comma after stability: The Release Owner must follow the following process, which is designed to ensure clarity, quality, stability, and auditability of each release:

Add a document providing an overview of releases along with the all-important release checklist. Fixes kata-containers#32. Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>

jodh-intel · 2018-04-23T08:04:38Z

Thanks @klynnrif - branch updated!

klynnrif

lgtm - thanks!

skip euleros build due to timeout reason

jodh-intel added the review label Apr 18, 2018

jodh-intel force-pushed the add-release-process branch from 304e6d9 to 925a454 Compare April 18, 2018 15:01

grahamwhaley requested a review from jcvenegas April 20, 2018 10:28

grahamwhaley approved these changes Apr 20, 2018

View reviewed changes

jcvenegas reviewed Apr 20, 2018

View reviewed changes

jodh-intel force-pushed the add-release-process branch from 925a454 to 8b53798 Compare April 20, 2018 13:12

klynnrif suggested changes Apr 21, 2018

View reviewed changes

docs: Add Release process docs

a070f18

Add a document providing an overview of releases along with the all-important release checklist. Fixes kata-containers#32. Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>

jodh-intel force-pushed the add-release-process branch from 8b53798 to a070f18 Compare April 23, 2018 08:04

klynnrif approved these changes Apr 23, 2018

View reviewed changes

egernst approved these changes Apr 24, 2018

View reviewed changes

egernst merged commit 2b47961 into kata-containers:master Apr 24, 2018

egernst removed the review label Apr 24, 2018

devimc pushed a commit to devimc/kata-documentation that referenced this pull request Sep 2, 2019

Merge pull request kata-containers#56 from liangchenye/time

56eb88b

skip euleros build due to timeout reason

		@@ -0,0 +1,79 @@
		Change release process, instead create a release candidate we can test the HEAD what will be the last commit using new automated obs package generation we can generate and test commits based on HEAD.


		- [ ] Get confirmation from metrics CI that performance is within acceptable limits.

		- [ ] Create an annotated tag for the new release version for the following repositories:


		Note that the "phase" element of the project encoded in the version strings needs to match for all components. For example, when a `beta` is released, the version string for all components should show `beta`.

		- [ ] Ensure all CI tests pass for all architectures.


		- [ ] Update public IRC channel with a link to the latest release.

		- [ ] Arrange for release to be communicated via other social media channels.


		For examples: `1.0.0`, `1.0.0-rc.5`, and `99.123.77+foo.bar.baz.5`.

		Semantic versioning is used since the version number is able to convey clear information about how a new version relates to the previous version. It can also provide assurances to allow users to know for example when they must upgrade compared with when they may wish to upgrade:


		## Release process

		The Release Owner must follow the following process, which is designed to ensure clarity, quality, stability and auditability of each release:

docs: Add Release process docs #56

docs: Add Release process docs #56

Conversation

jodh-intel commented Apr 18, 2018

jodh-intel commented Apr 18, 2018

jcvenegas commented Apr 18, 2018

jodh-intel commented Apr 18, 2018

jcvenegas commented Apr 18, 2018 • edited Loading

jodh-intel commented Apr 20, 2018

grahamwhaley left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcvenegas left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcvenegas commented Apr 20, 2018

jodh-intel commented Apr 20, 2018

jodh-intel commented Apr 20, 2018

egernst commented Apr 20, 2018

klynnrif left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jodh-intel commented Apr 23, 2018

klynnrif left a comment

Choose a reason for hiding this comment

jcvenegas commented Apr 18, 2018 •

edited

Loading