First pass at 1.8 schedule #305
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,91 @@ | ||
| # Proposed timeline for 1.8 | ||
| We will begin the 1.8 release the first week of July 2017. | ||
|
|
||
| The proposal below is similar in layout to the 1.7 plans with some | ||
| modifications: | ||
| - as before, key days aren't Fridays, since it can be hard to end milestones right up against weekends | ||
| - new in 1.8 | ||
| * alpha's should not be cut unless all master-release-blocking tests are passing | ||
| * release notes for planned features done 2 weeks out from feature freeze | ||
| * docs PRs deadlines ahead of release | ||
|
|
||
| ## 1.8 Release Schedule Key Dates | ||
| - July 5 (Weds) coding start (7w) | ||
| - July 12th (Weds): v1.8.0-alpha.1 | ||
| - July 26th (Weds): v1.8.0-alpha.2 | ||
| - Aug 1 (Tues): Feature Freeze | ||
| - Aug 9 (Weds): v1.8.0-alpha.3 | ||
| - Aug 23 (Weds): v1.8.0-alpha.4 | ||
| - Sept 1 (Fri): Code Freeze | ||
| - Sept 6 (Weds): v1.8.0-beta.0, v1.9.0-alpha.0 | ||
| - Sept 13 (Weds): v1.8.0-beta.1 | ||
| - Sept 18th (Mon): v1.9.0-alpha.1 | ||
| - Sept 20th (Weds): v1.8.release-candidate | ||
| - Sept 27th (Weds): v1.8.0 release! | ||
|
|
||
| ## 1.8 Details | ||
|
|
||
| ### July 5 - Sept 1 | ||
| - 8 week coding period | ||
| - Release 1.8 alphas every 2 weeks | ||
|
There was a problem hiding this comment. i suggest we require all release tests to be passing to cut an alpha There was a problem hiding this comment. Agreed. The more the alpha releases are like treated like real releases, the better. There was a problem hiding this comment. To clarify:
There was a problem hiding this comment.
I think this makes sense at least until we can get better ownership of non-blocking suites. If we do include others at this point we should explicitly list them since the status quo is currently having some bad jobs. This would make sense for important suites that are likely non-blocking for test duration reasons like serial and soak.
The "3 in a row" is the standard I've seen for the past few releases but it's generally been up to human discretion. We should decide on an exact criteria and ideally have it machine enforced. There was a problem hiding this comment. I believe we need to look at overall test stability when it comes to making the call. Philosophically speaking, a disruptive release is far worse than a disruptive wait. There was a problem hiding this comment. Decision: don't cut alpha until master-blocking-tests are passing |
||
| - Alphas only cut if [release-master-blocking](https://k8s-testgrid.appspot.com/release-master-blocking) are passing | ||
| - July 12th (Weds): v1.8.0-alpha.1 | ||
| - July 26th (Weds): v1.8.0-alpha.2 | ||
| - Aug 1st (Tues): Feature Freeze: all features going into release should | ||
| have an associated issue in the features repo | ||
| - Aug 8th (Tues): First draft of feature related release notes due | ||
| - Aug 9th (Weds): v1.8.0-alpha.3 | ||
| - Aug 15th (Tues): Final draft of feature related release notes due | ||
| - Aug 23rd (Weds): v1.8.0-alpha.4 | ||
|
|
||
| ### Sept 1 (Fri) - Sept 14 (Thurs) | ||
| - Sept 1st Begin Code Freeze (Code Slush) | ||
| * Hard deadline for feature-related PRs to be in submit queue | ||
| * Add milestone restriction on submit queue. | ||
| * Community Feature Burndown Meetings held two or three times until release week (then every day). For those interested in joining please join [Kubernetes Milestone Burndown Group](https://groups.google.com/forum/#!forum/kubernetes-milestone-burndown) | ||
| * Focus on bugfix, test flakes and stabilization | ||
| * Ensure docs and release notes are written | ||
|
There was a problem hiding this comment. @pwittrock so we mention release notes and docs up here at the start of code freeze, but agree we're not spelling out enough In terms of release notes, we should now have enough to collate one-line descriptions of high-level features that are being added, deprecations or removals that are happening, and improvements that are being made (eg: scrape the one-line release description from features repo issues, or copy-pasta from a manually managed spreadsheet) This should be enough to answer "but why should I care about the beta?" with a bite-sized blog or e-mail of "you can try out X, we've made Y way more usable, and you can can get a jump on the deprecation of Z" In terms of docs, I'm guessing by now there should be enough content for a tech review? @kubernetes/sig-docs-maintainers There was a problem hiding this comment. @spiffxp this all seems spot on. Those three criteria must be satisfied. We should have a document go/no-go date set as well. Documentation (the one-liner) should be a blocker for matriculation IMO since the burden is low and the risk of end-user "feature discovery" is very high. Without this documentation, we lose our most valuable asset: transparency. There was a problem hiding this comment. how would we feel about making "Release note deadline" two weeks after feature freeze? There was a problem hiding this comment. +1 @calebamiles. But I'd propose to set this deadline for docs as well, and at the same time, when the code freeze should happen. There was a problem hiding this comment. I think it makes sense collect the full release notes at the time of code freeze. Collecting and announcing what features are gonna be in the release on a high level should be done as soon as possible after the feature freeze. It will serve as the base for the release notes, which will be enhanced at the time of the code freeze with important PRs, action required/deprecation/etc items etc. There was a problem hiding this comment. @calebamiles I am for that being when they are finalized, but not necessarily due. I acknowledge that the burden of getting the feature AND docs over the line at the same time can be difficult. But, SIGs should have that as part of the planned workstream as much as the feature itself. Would a one-week grace period serve the purpose? After that, it would be time to have discussions with SIGs and individuals to ensure it gets done. There was a problem hiding this comment. Decision: Relnotes for feature due after feature freeze (see dates above) |
||
| * Identify all features going into the release, and make sure alpha, beta, ga is marked in features repo | ||
| * Release team to create release notes draft doc and share broadly | ||
| - Sept 6th (Weds): v1.8.0-beta.0 | ||
| * Branch Manager to create `release-1.8` branch. | ||
| * v1.9.0-alpha.0 is cut | ||
| * Test-infra lead to set up CI for branch. | ||
| * Begin regular fast-forwards (at least daily to keep CI up-to-date). | ||
| - Sept 8th | ||
| * Docs PRs must be open for tech review | ||
| - Sept 13th (Weds): End of Code Freeze | ||
| * v1.8.0-beta.1 cut | ||
| * Final fast-forward of release branch. | ||
| * After this, all changes for the release must now be cherrypicked in batches by branch | ||
| manager. | ||
| * Remove milestone restriction on submit queue. Bot drains backlog over the | ||
| weekend. | ||
|
|
||
| ### Sept 15 - Sept 27 | ||
| - Sept 15th (Fri) | ||
| * Docs PRs lgtm'd and ready for merge | ||
| - Sept 18th (Mon): v1.9.0-alpha.1 | ||
| - Sept 20th (Weds): v1.8.release-candidate | ||
| * RC means no known release-blockers outstanding. | ||
| * Only accept cherrypicks for release-blockers. | ||
| * Announce on mailing lists, Twitter, etc. to ask people to build and test the RC and submit feedback | ||
| * Perhaps managed k8s providers make rc.1 available on early access channels. | ||
| * More RCs as needed to verify release-blocking fixes. | ||
|
There was a problem hiding this comment. We need to have something about release notes and docs on here. When they are started, and what the dates for milestones are. I suggest release notes for completed issues must be done by SIGs 1 week before the release date. There was a problem hiding this comment. By now, we're 1 week out from release. From a release notes perspective, I'm in full agreement we should basically have everything documented, all we should be changing by now are structural edits or last minute Known Issues. We should have enough in place that the release branch manager could cut a copy of CHANGELOG.md with all the release notes incorporated (assuming that's where they still land) IMO what should not be happening by now is the addition of features or large structural changes in the release notes. I feel like I saw both happen the final week of the previous release. From a docs perspective, I would hope we're basically at a live copy of all of the docs, with grammar edits and spell checking at this point. Historically that has not been the case though. What is reasonable to expect by now? @kubernetes/sig-docs-maintainers There was a problem hiding this comment. Honestly, at 1 week out for 1.7, half the 22 docs were merged and good to go. A couple days later (that Fri), we were at 80%. Even the day of the original release date, we were scrambling to get a couple docs reviewed and merged because one snuck in last minute and another one hadn't been completed and ready for review until that day. It follows sort of an exponential decay pattern. We can set the deadlines earlier, but there will still be a few stragglers at the end. |
||
| - Release 1.8 on Sept 27 (Wednesday) | ||
|
|
||
|
|
||
| # Key features | ||
| [Feature tracking spreadsheet | ||
|
There was a problem hiding this comment. Spreadsheet link to be provided by @idvoretskyi |
||
| link]() | ||
|
|
||
| ## Operational Changes | ||
| 1. For the 1.8 release, the [release team](https://github.com/kubernetes/features/blob/master/release-1.8/release_team.md) | ||
| will use the following procedure to identify release blocking issues | ||
| 1. Any issues listed in the [v1.8 milestone](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20milestone%3Av1.8) | ||
|
There was a problem hiding this comment. FYI, my proposal is that issues are automatically moved out of the milestone unless they are labeled critical-urgent and have a SIG owner. See link here There was a problem hiding this comment. Let the 1.8 release team decide on this |
||
| will be considered release blocking. It is everyone's responsibility to move non blocking issues out of the `v1.8` milestone. Items targeting 1.8 can be moved into the `v1.8` milestone. | ||
| milestones **or the release will not ship** | ||
|
|
||
| # Contact us | ||
| - [via slack](https://kubernetes.slack.com/messages/sig-release/) | ||
| - [via email](mailto:kubernetes-release@googlegroups.com) | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,11 @@ | ||
| | **Role** | **Name** (**GitHub/Slack ID**) | **Shadow Name(s) (GitHub/Slack ID), ...** | ||
|
There was a problem hiding this comment. Is the "Shadow role" still actual? For 1.7 we had only Lead release manager shadowed. There was a problem hiding this comment. Personally I would like to see it remain present. I can shadow someone this release. There was a problem hiding this comment. +1 I like how it provides a lower commitment avenue to be involved in a release There was a problem hiding this comment. It might be moot if we don't find someone to fill it. |
||
| | ------ | ------ | ------ | | ||
| | Lead | | | | ||
| | Secondary | | | | ||
| | Features || | | ||
| | Branch Manager | | | | ||
| | Test Infra | | | | | ||
| | Docs || | | ||
| | Bugs | | | | | ||
| | Upgrade Testing / CI Signal| | | | | ||
| | Patch Release Manager | | | | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aug 8: release notes draft for features due
Aug 15: hard deadline for feature related relnotes