Proposal for automated management of issues targeted to release miles… #752

pwittrock · 2017-06-21T23:52:39Z

…tones

grodrigues3 · 2017-06-22T00:15:00Z

contributors/devel/release/issues.md

+
+- *issue owners*: creator, assignees, and user who moved the issue it into a release milestone
+- *Y days*: refers to business days (using the location local to the release-manager M-F)
+- *post feature freeze* / *code slush*: starts when the master branch only accepts PRs for the release milestone


Feature Freeze is an overloaded term. I know PM also uses this to refer to when no additional issues/features are made available in the features repo.
https://github.com/kubernetes/features/blob/master/release-1.7/release-1.7.md

ah. :( should we just call this code slush?

grodrigues3 · 2017-06-22T00:18:14Z

contributors/devel/release/issues.md

+The severity is used to triage which issues the release team needs to track as part of cutting
+a release.  As the release date approaches, release blocking issues are expected to be updated
+frequently and have an issue owner present at all burn down meetings until the issue is resolved.
+


are these synonymous with priority/ labels. Will there ever be a priority/critical-urgent issues that is not a release-blocker? Are we just being very explicit?

I am wondering the same thing. As proposed, priority/critical-urgent seems to imply release/blocker and priority/important-{soon,longerm} seems to imply release/non-blocker?

Yes they do - and the doc says they need to match. I wrote this as having both labels because it makes it clear that only critical-urgent issues are release/blocker issues and all critical-urgent issues are release/blockers. Do you think I should just drop the release/blocker labels?

I'd vote that less is more

Removed release-blocker

Yes, I think release/ labels are unnecessary. It should be enough that only issues labelled priority/critical-urgent are release blockers.

grodrigues3 · 2017-06-22T00:19:08Z

contributors/devel/release/issues.md

@@ -0,0 +1,193 @@
+# Targeting issues and PRs to release milestones


This document is relevant across repos right?

grodrigues3 · 2017-06-22T00:23:02Z

contributors/devel/release/issues.md

+- `kind/bug`: Fixes a bug.
+  - were not known at the time the feature was implemented.
+- `kind/feature`: New functionality.
+- `kind/documentation`: Documentation updates for new features or bug fixes.


shouldn't all docs changes be in the docs repo. when would we use this label?

good point. deleted

grodrigues3 · 2017-06-22T00:23:59Z

contributors/devel/release/issues.md

+
+    Additional instructions available [here](<link to this doc>)
+    ```
+  - **If required labels are not applied within 2 days of being moved to the milestone,  the issue is moved back out of the milestone.  (unless it is critical-urgent)**


I think it says 3 days above

marun

Would it be worth separating out the timelines for the bots to expect or take action rather than sprinkling it everywhere? I'm guessing these intervals are likely to be volatile.

marun · 2017-06-22T00:35:04Z

contributors/devel/release/issues.md

+
+## Definitions
+
+- *issue owners*: creator, assignees, and user who moved the issue it into a release milestone


marun · 2017-06-22T00:35:52Z

contributors/devel/release/issues.md

+bot will attempt to contact the issue creator 3 times (over 3 days)
+before automatically removing the issue from the milestone.
+
+Labels categories:


s/Labels/Label/

marun · 2017-06-22T00:43:16Z

contributors/devel/release/issues.md

+The severity is used to triage which issues the release team needs to track as part of cutting
+a release.  As the release date approaches, release blocking issues are expected to be updated
+frequently and have an issue owner present at all burn down meetings until the issue is resolved.
+


I am wondering the same thing. As proposed, priority/critical-urgent seems to imply release/blocker and priority/important-{soon,longerm} seems to imply release/non-blocker?

marun · 2017-06-22T00:49:01Z

contributors/devel/release/issues.md

+    ```
+  - **If required labels are not applied within 2 days of being moved to the milestone,  the issue is moved back out of the milestone.  (unless it is critical-urgent)**
+  - Bot checks that release/blocker issues have critical-urgent priority.  (Can be automatically applied).
+2. If labels change, bot checks that the needed lables are present and comments with updated meaning.


s/lables/labels/

marun · 2017-06-22T00:50:03Z

contributors/devel/release/issues.md

+    - after 2 days without a reply, bot follows escalation procedure derived from priority label
+      - important-longterm, remove from milestone and notify the owners
+      - important-soon, escalate to SIG daily for 2 days.
+    - removal should add the `release/remove-from-milestone` label and contain the following message


s/remove/removed/ ?

marun · 2017-06-22T00:50:54Z

contributors/devel/release/issues.md

+      ETA: ???
+      Risks: Root cause unknown.
+      ```
+    - `release/needs-attention`


Is there detail missing here?

marun · 2017-06-22T00:51:42Z

contributors/devel/release/issues.md

+    - `release/needs-attention`
+4. 2 weeks after feature freeze
+  - **priority/important-* issues**
+    - bot comments mentioning issue owners, expects the issue to be escalated in priority or removed from milestone


What's the timeline for removal?

2 days? Added as a strawman

marun · 2017-06-22T00:52:04Z

contributors/devel/release/issues.md

+    ```
+    **Action Required**:
+    This issue is marked as priority/important-x, and is in the 1.y milestone.  Only critical-urgent issue
+    are being tracked for the 1.y release.  Escalate the priority to critical-urgent immediately, **or the issue


s/immediately/within 24h/ ?

marun · 2017-06-22T00:54:29Z

contributors/devel/release/issues.md

+
+## Issues tracked in other repos
+
+Some issues are filed in repos outside the [kubernetes repo].  For these repo's issues


I think this is necessary, but maybe puts an unfair burden on sigs that are devolving their work away from the main repo. Could this be automated?

Good point. We could start using this: https://github.com/issues for x-repo queries.

Or this rather: https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+milestone%3Av1.7+label%3Asig%2Fcli+org%3Akubernetes

marun · 2017-06-22T01:12:25Z

Should this proposal also include bot enforcement of the requirement that PRs in the milestone have an associated issue unless a label (e.g. 'no-issue-required') is applied?

pwittrock · 2017-06-22T03:02:22Z

@marun

Should this proposal also include bot enforcement of the requirement that PRs in the milestone have an associated issue unless a label (e.g. 'no-issue-required') is applied?

I can add that, but want to keep the document scoped to something we can get consensus on. When would this be enforced? Code slush, or throughout the release?

ncdc · 2017-06-22T17:02:05Z

contributors/devel/release/issues.md

+Priority label used by the bot to determine escalation path before moving an issues
+out of the release milestone.
+
+- `priority/critical-urgent`: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels.- `priority/critical-urgent`: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels.


duplicated content

ncdc · 2017-06-22T17:03:42Z

contributors/devel/release/issues.md

+The severity is used to triage which issues the release team needs to track as part of cutting
+a release.  As the release date approaches, release blocking issues are expected to be updated
+frequently and have an issue owner present at all burn down meetings until the issue is resolved.
+


I'd vote that less is more

ncdc · 2017-06-22T17:04:48Z

contributors/devel/release/issues.md

+This will also be used to escalate to the correct SIG GitHub team.
+
+- `kind/bug`: Fixes a bug.
+  - were not known at the time the feature was implemented.


Is this line necessary?

unfortunately yes.

Seems obvious, but I'll let it go ;-)

Update this with some more clarity. The purpose of the label is to get a feel for how many issues we are surprised with. However, it is common to see bug fixes during code slush for issues that have been around since the last release, or were known at the time the feature was developed, but not fixed, to get the feature in before code slush (no "feature development" accepted at this time). The "bug" is then fixed during code slush. Both of these cases create noise when trying to determine - how many issues did we discover during and after code slush that we would have went out with had things not baked for 3 weeks.

Oh! I wasn't asking if kind/bug was required. I totally accept that. I was asking if the text "were not known at the time the feature was implemented." was necessary.

:). I'll remove it.

marun · 2017-06-23T00:28:42Z

@pwittrock

I can add that, but want to keep the document scoped to something we can get consensus on. When would this be enforced? Code slush, or throughout the release?

Only code slush, when traceability becomes critical.

cblecker · 2017-06-23T00:35:09Z

contributors/devel/release/issues.md

+1. An issue is added to the current release milestone (either through creation or update)
+  - Bot automatically applies the ''
+  - Bot checks to make sure all required labels are set on the issue
+  - Iff any labels are missing, comment listing the missing labels and include a link to this document.  Mention all issue owners.


Is this a typo, or intended as "if and only if"?

If and only if. This has caused confusion before, so just typed it out.

cblecker · 2017-06-23T00:35:15Z

contributors/devel/release/issues.md

+
+    Additional instructions available [here](<link to this doc>)
+    ```
+  - Iff all labels are present, comment summarizing the state.  Mention all issue owners.


marun · 2017-06-23T00:42:09Z

contributors/devel/release/issues.md

+
+- `priority/critical-urgent`: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels.
+  - considered a release blocking issue
+  - post code slush: issue owner update frequency: every 3 days


s/post// (for parity with code freeze below)

Or is 'code slush' a point in time vs 'code freeze' being an interval?

good point. code slush is an interval

marun · 2017-06-23T00:45:02Z

contributors/devel/release/issues.md

+  - would require a patch release if left undiscovered until after the minor release.
+- `priority/important-soon`: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts.
+  - not considered a release blocking issue
+  - would not require a patch release


Should this line and the one below also apply to priority/important-longterm? So the only difference between the 2 would be the mount of escalation?

Yup. Updated to clarify this.

marun · 2017-06-23T00:46:55Z

contributors/devel/release/issues.md

+- Priority
+- Issue type
+
+### SIG owner label


How to handle test infra and issues related to gce/gke/etc? I think we started assigning them to sig/release for 1.7, should that continue for 1.8?

And maybe issues in this vein (related to the infrastructure that supports development rather than the software being developed) require their own issue type?

I think for GCE/GKE, there's going to be a new sig-gcp created if the mailing list discussion pans out. test-infra would go to sig-testing?

I'm not sure test-infra to sig-testing makes sense. afaik their missions are different.

Using sig/testing

marun · 2017-06-23T01:34:49Z

contributors/devel/release/issues.md

+## Workflow
+
+1. An issue is added to the current release milestone (either through creation or update)
+  - Bot automatically applies the ''


No idea. deleted

marun · 2017-06-23T01:37:00Z

contributors/devel/release/issues.md

+    ```
+  - **If required labels are not applied within 3 days of being moved to the milestone,  the issue is moved back out of the milestone.  (unless it is critical-urgent)**
+2. If labels change, bot checks that the needed labels are present and comments with updated meaning.
+3. Post-code slush


s/Post-// ?

marun · 2017-06-23T01:39:29Z

contributors/devel/release/issues.md

+      ```
+      ACK.  In progress
+      ETA: DD/MM/YYYY
+      Risks: Complicate fix required


s/Complicate/Complicated/

Thanks. Done

marun · 2017-06-23T01:43:25Z

contributors/devel/release/issues.md

+SIGs will have issues needing attention escalated through the following channels
+
+- Comment mentioning the sig team appropriate for the issue type
+- Email the SIG googlegroup list


Im assuming the the bot has persistent configuration. How hard will it be to associate sig labels with email addresses?

Should be easy. We should be able to just scrape / copy them from here:
https://github.com/kubernetes/community/blob/master/sig-list.md

Updated with a comment.

pwittrock · 2017-06-30T16:17:41Z

@marun

I can add that, but want to keep the document scoped to something we can get consensus on. When would this be enforced? Code slush, or throughout the release?
Only code slush, when traceability becomes critical.

SGTM. I need to create another proposal for PRs and enforcing labels and comments there for release notes anyway.

pwittrock · 2017-06-30T16:18:51Z

@ncdc

I'd vote that less is more

Cleaned it up a bit.

…tones

pwittrock · 2017-06-30T16:20:37Z

Most of the comments seemed like non-blockers. I have attempted to addressed all of them. If they need to be refined further, I can create a follow up.

Self merging this since we seem to have achieved lazy consensus.

Thanks for your feedback @ncdc @marun @cblecker @grodrigues3

Signed-off-by: Jacek Ewertowski <jewertow@redhat.com>

pwittrock requested review from marun, grodrigues3, dchen1107 and saad-ali June 21, 2017 23:52

k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Jun 21, 2017

pwittrock mentioned this pull request Jun 22, 2017

Document a process for keeping tests passing against master #744

Merged

grodrigues3 reviewed Jun 22, 2017

View reviewed changes

marun reviewed Jun 22, 2017

View reviewed changes

pwittrock assigned calebamiles, marun and monopole Jun 22, 2017

ncdc reviewed Jun 22, 2017

View reviewed changes

cblecker reviewed Jun 23, 2017

View reviewed changes

marun reviewed Jun 23, 2017

View reviewed changes

pwittrock mentioned this pull request Jun 30, 2017

First pass at 1.8 schedule kubernetes/enhancements#305

Merged

pwittrock force-pushed the issues branch from 37f1ff2 to 7cd9a7f Compare June 30, 2017 16:14

Proposal for automated management of issues targeted to release miles…

edc74dc

…tones

pwittrock force-pushed the issues branch from 7cd9a7f to edc74dc Compare June 30, 2017 16:19

pwittrock merged commit 7b8fb29 into kubernetes:master Jun 30, 2017

danehans pushed a commit to danehans/community that referenced this pull request Jul 18, 2023

Add jewertow to the member list (kubernetes#752)

3f12359

Signed-off-by: Jacek Ewertowski <jewertow@redhat.com>

		@@ -0,0 +1,193 @@
		# Targeting issues and PRs to release milestones


		## Definitions

		- issue owners: creator, assignees, and user who moved the issue it into a release milestone


		## Issues tracked in other repos

		Some issues are filed in repos outside the [kubernetes repo]. For these repo's issues

Proposal for automated management of issues targeted to release miles… #752

Proposal for automated management of issues targeted to release miles… #752

Conversation

pwittrock commented Jun 21, 2017

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marun 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

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

marun commented Jun 22, 2017

pwittrock commented Jun 22, 2017

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

marun commented Jun 23, 2017

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

marun Jun 23, 2017 • edited Loading

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

marun Jun 23, 2017 • edited Loading

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pwittrock commented Jun 30, 2017

pwittrock commented Jun 30, 2017

pwittrock commented Jun 30, 2017

marun Jun 23, 2017 •

edited

Loading

marun Jun 23, 2017 •

edited

Loading