kubernetes / sig-release Goto Github PK
View Code? Open in Web Editor NEWRepo for SIG release
License: Apache License 2.0
Repo for SIG release
License: Apache License 2.0
According to the timeline, we should cut v1.9.0-alpha.3 on Wed, Nov 15.
This is a tracker for burning down release-blocking test failures and recording release cut status.
Kubernetes v1.10.1 has been built and pushed.
The release notes have been updated in CHANGELOG-1.10.md with a pointer to it on github.
cc @kubernetes/sig-release-members
According to the timeline, we should cut v1.9.0-beta.1 on Wed, Nov 29
This is a tracker for burning down release-blocking test failures and recording release cut status.
We need a regular meeting cadence for the core 1.8 release team separate from SIG-Release.
It says: kubernetes/kubernetes#55065 (comment)
Note: This pull request is marked as priority/critical-urgent, and must be updated every 1 day during code freeze.
Example update:
ACK. In progress
ETA: DD/MM/YYYY
Risks: Complicated fix required
For this part:
Example update:
[1]
ACK. In progress
ETA: DD/MM/YYYY
Risks: Complicated fix required
What should the PR author do to update? Just commenting something as [1] shows or commenting anything would be OK?
This is an action item issue to make sure anago takes care of pushing debs/rpms in v1.8
Now it's a really painful process to have to ping various Googlers to push the packages manually
The proposed way of fixing this is by making a new GCS bucket that is set up as a deb/rpm repo.
It must maintain the structure of the current apt.kubernetes.io
repo.
Then, in the release process, packages will be built and published by just pushing to GCS.
It's also a lot easier to manage ACLs with a GCS bucket compared to the Google-internal stuff we're currently depending on. (Where the source code/tools used are confidential)
For converting .deb
packages to something pushable to GCS we can use https://github.com/spotify/debify
I don't know what's the best way to create a yum repo, but will look for something useful
cc @david-mcmahon @ixdy @jdumars @mikedanese @pipejakob @wojtek-t
I propose that we lift code freeze on Wed, Dec 13. We expect all the current PRs in the milestone to merge before then.
This will involve undoing the submit queue config from #32.
However, we will maintain the milestone bot config in freeze mode until the 1.9.0 release goes out.
There is an outstanding PR to finalize the release timeline, to be discussed and merged Friday, July 21st at 21:00 UTC. Outstanding question is how best to move the final version into this repository.
A new @k8s-release-robot user has been added to the project in order to facilitate the transfer of Kubernetes software release functions from Googlers (creating releases only on a desktop) to both Googler and non-Googler Kubernetes project contributors creating releases via https://cloud.google.com/container-builder.
Basic doc on functionality can be found here in the kubernetes/release repo.
In order for @k8s-release-robot to prepare and deliver releases via GCB, it must have write access to kubernetes/sig-release in order to assign owners and write labels to the release tracking issue created during a release and it must have 'repo admin' rights on kubernetes/kubernetes in order to push branches, tags and source code artifacts (CHANGELOG*.md, swagger.json) during releases. Essentially membership in @Kubernetes/kubernetes-release-managers.
We need to fill the bug tracking release role.
According to the proposed schedule, feature freeze is Fri, Oct 27.
I want to send a reminder to k8s-dev soon, but I wanted to check if we're asking for anything different this cycle.
@idvoretskyi Do you require anything at feature freeze other than that the issues are populated in the features repo?
@Bradamant3 There's something in the proposed schedule about "release talking points" and "sig themes" being due at feature freeze time. Can you elaborate on what we need the SIGs to provide?
When the release-1.10 branch was created, we ended up in a new situation where the branch point commit was tagged with both the master branch (alpha) and release branch tags (beta). This was due to a recent commit to the tooling which excluded a change to the branch at branch time which provided the opportunity to then tag the branch at branch-point + 1.
The immediate remedy here to set the master branch straight so it is 'git describe'ing correctly was to remove the (beta) tag from the commit.
Proposal 1:
Proposal 2:
cc @calebamiles @enisoc @kubernetes/test-infra-maintainers @jdumars
ref kubernetes/kubernetes#59895
We need to ensure historical documentation is moved here for context and ease of use. This process needs to be non-destructive since this change has not been radiated to the larger community.
As a Release Team member shadowing the Features Lead role, it should be my responsibility to explicitly document and / or revise documentation that corresponds to that role.
Documentation should delineate:
Here's a good example of what the docs might look like.
We should also then cross-link that documentation to the features repo.
/cc @idvoretskyi
/assign
We don't have release tar attached in the v1.10.0 release page https://github.com/kubernetes/kubernetes/releases/tag/v1.10.0.
This issue is to pick up some debate/pointers from folks with more experience in k8s and its maintenance about the probable release versioning that is ideal for projects which have been separated out into their own github repos with the intention of independent maintenance and release.
As the project until now was maintained and released as part of k8s releases, there are 2 alternatives to use:
Both have some pros and cons and there is no clear precedent.
We have an example of client-go, which maintains its own versioning scheme and publishes a compatibility matrix (probably not a very good example as its only a library for clients). We also have an example of tools like kubeadm and kubectl (which probably are candidates which will be maintained externally) but haven't reached there yet and the code and binaries still map to k8s core. It makes lot of sense to follow some scheme which by version itself can provide enough info to the reader about its compatibility with any given k8s release.
I initiated a brief doc a while ago to collect comments. This issue is an attempt to share that will a wider audience and/or to collect feedback/suggestions for the same here. Please point me in the right direction if this is not the place for this topic.
cc @kubernetes/sig-multicluster-misc
Use an OWNERS file, /approve, /lgtm to allow people to merge PR's into this repo:
/assign
This is a tracker to discuss extending some form of the milestone automation we have for issues to apply to pull requests.
The milestone has a different meaning on issues and PRs during code freeze:
Note that these criteria can be independent: A PR might be allowed during freeze if it's approved for the milestone, even if it has no issue (/approve no-issue
). Also, a PR associated with an issue that's approved for the milestone is not necessarily making a code change that's permissible during freeze.
For this reason, I propose applying milestone automation separately to issues and PRs, without trying to cross-reference the milestone status of issues linked from PRs. SIGs will need to separately approve the problem (issue) and the particular solution (PR) for the milestone.
The automation for PRs will help us do things like remove everything but release-blockers (priority/critical-urgent
) from the milestone upon entering code freeze. It also would help communicate milestone requirements to PR authors during slush and freeze.
This role needs to be fully defined by SIG-Release.
Some PRs' release notes have markdown format symbols (e.g., -
, *
), this leads to bad format in the CHANGELOG (see 1.9 changelog).
kubernetes/kubernetes#54175
kubernetes/kubernetes#52792
kubernetes/kubernetes#53043
We may not avoid PR authors to use such symbols, so should we address this case in the release note tool? @roycaihw
We need to fill the documentation manager role.
Due to the changes from PR milestone automation (#26), we now have a hard requirement that kind, sig and priority labels need to be populated for PRs. I propose that we add to our automation to make that easy, specifically:
If a PR is linked to an issue, and the PR has no kind, sig, or priority labels, the kind, sig and priority labels from the linked issue should be copied to the PR automatically.
Obstacle: Github's notion of a PR being linked to an issue is rather loose; basically, if the PR is mentioned at all in the issue. This could lead to PRs being tagged that are only mentioned tangentally. Is there a useful way around this?
This issue is for status updates on 1.10 issues for release tracking.
It's been confusing to have to bounce between multiple repos to get details about the release and the release team.
If we can't outright remove the files in kubernetes/features we should at least tombstone them as links to copies that exist here.
No explicit due date or priority on this, it's a thing I'm interested in but I'd be just as happy if someone other than me got this done.
Kubernetes has been built and pushed.
The release notes have been updated in CHANGELOG-1.11.md with a pointer to it on github.
According to the timeline, we should cut v1.9.0 on Wed, Dec 13
This is a tracker for burning down release-blocking test failures and recording release cut status.
According to the timeline, we should start Code Freeze on Wed, Nov 22 (after 3pm PST).
As far as I know, this involves the following:
additional-required-labels
.
status/approved-for-milestone
and priority/critical-urgent
labels.milestone-modes
and milestone-freeze-date
.
v1.9
to freeze
.TBD
.@marun Does that look right to you?
cc @jberkus
According to the timeline, we should start Code Slush on Mon, Nov 20 (after 3pm PST).
As far as I know, this involves the following:
do-not-merge-milestones
and additional-required-labels
.
status/approved-for-milestone
label.milestone-modes
and milestone-freeze-date
.
v1.9
to slush
.Wed, Nov 22
.@marun Does that look right to you?
cc @jberkus
There is an effort underway to generate release notes from PRs, grouped by SIG and area labels. As the release team, we should engage with them to help test the tool and give feedback.
We need to fill the testing lead role.
wrong repo
According to the planned timeline, we should cut alpha.2 on Wed, Nov 1.
@dashpole Can you try a mock build with anago to start getting your workstation set up? Let me know if you run into any trouble.
@spiffxp @detiber How far from green are we on release-master-blocking tests? Can we at least have owners for all the failures by a week from now?
This is a tracker for writing a concrete policy for deciding whether a given job should be release-blocking.
One of the primary purposes of this SIG repository is to add more structure than previously existed in the kubernetes/community
repo. I propose the following directory structure for the repo
├── LICENSE
├── members.md
├── README.md
├── release-process-documentation
│ ├── documentation-guides
│ │ ├── update-release-docs.md
│ │ └── updating-docs-for-feature-changes.md
│ └── github-guides
├── releases
│ ├── release-1.2
│ ├── release-1.3
│ ├── release-1.4
│ ├── release-1.5
│ ├── release-1.6
│ └── release-1.7
├── security-release-process-documentation
│ └── security-release-process.md
└── ephemera
├── cherry-picks.md
├── issues.md
├── patch-release-manager.md
├── README.md
├── scalability-validation.md
└── testing.md
where
release-process-documentation
stores process docs for the release team and the communityreleases
contains historical information about previous releases such as the team list and the release notes draftsecurity-release-process-documentation
provides quick access to information about our security release processephemera
is a staging directory which should be generally emptyThe open patch manager role needs to be filled by a Google engineer due to constraints in the CI implementation.
@zacharysarah @Bradamant3 @nwoods3
While cleaning up the release timeline, I only kept items I understand -- mostly code/build-related.
I'd like help from the docs/relnotes/marketing leads to repopulate and document deadlines for things you need from other teams (devs, SIGs, etc.).
Here are some of the things that were previously listed in the timeline that I didn't understand well enough to commit to:
I'd like to clarify what deliverable is needed, and who is responsible for delivering it. For example, who writes the release talking points? If it's something the release team does, what do we need from SIGs before we can get it done?
This is a tracker for status updates on 1.9 issue burndown.
This role was identified as a key missing element in the 1.7 Release retrospective. We need to define the role, accountabilities, and activities ASAP as well as find someone to fill the role.
Code freeze will be enforced by EOD September first. Activities related to the freeze will be documented here.
According to the timeline, we should create the release-1.9
branch and start setting up test infra on Thu Nov 16.
@dashpole You can create the branch with anago
, and then we'll need you to run branchff
every day to keep it up to date. Let me or @david-mcmahon know if you have any questions.
@BenTheElder Do you have access to any instructions from previous release test-infra leads on what needs to be set up?
Example: No LICENSE file:
According to the timeline, we should cut v1.9.0-beta.2 on Wed, Dec 6.
However, we might consider cutting on Mon, Dec 4, if the exception requests granted until Dec 1 have merged.
Initially opened by @calebamiles at https://github.com/kubernetes/sig-release/projects/2
Release role recruitment has been underway for a few weeks, and the release lead and secondary need to be finalized.
Who are the SIG leads? What is the mailing list? When are meetings? Where are the notes and recordings?
This is all missing from here and the community repo. See kubernetes/community#891.
Kubernetes v1.7.16 has been built and pushed.
The release notes have been updated in CHANGELOG-1.7.md with a pointer to it on github.
cc @kubernetes/sig-release-members
We should start collecting the documents sprinkled in kubernetes/community
which should be maintained by SIG Release
Volunteer needed from Google to fill the Test Infrastructure role.
We are planning an alpha release on 8/23 with the following dependencies:
I will report status on this issue as we move forward.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.