Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] contrib & devel guide: pull in issue doc from sig-release/ephemera #2430

Closed
wants to merge 1 commit into from

Conversation

tpepper
Copy link
Member

@tpepper tpepper commented Jul 27, 2018

The sig-release repo has a set of old documentation looking for a
better home. The issues.md document there describes how a developer
targets an issue (or PR) to a milestone release. This logically
fits better in the community/contributors/devel/ guide, so this commit
brings it in and a parallel commit will remove it from the other repo.

See also kubernetes/sig-release#240

Signed-off-by: Tim Pepper [email protected]

@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. area/contributor-guide Issues or PRs related to the contributor guide sig/contributor-experience Categorizes an issue or PR as relevant to SIG Contributor Experience. labels Jul 27, 2018
@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Jul 27, 2018
@tpepper
Copy link
Member Author

tpepper commented Jul 27, 2018

tpepper pushed a commit to tpepper/sig-release that referenced this pull request Jul 27, 2018
This document describes how the community targets issues and PRs
to a milestone release.  As such I think it fits best in the developer
guide.  A portion of the information on escalating issues relates
to the release team, but is already covered in the release-team
role handbooks and that escalation process is good to have visible
to developers broadly so they understand that they're liable to be
pinged by the release team for clarifying information.

See also kubernetes/community#2430

Signed-off-by: Tim Pepper <[email protected]>
tpepper pushed a commit to tpepper/sig-release that referenced this pull request Jul 27, 2018
This document describes how the community targets issues and PRs
to a milestone release.  As such I think it fits best in the developer
guide.  A portion of the information on escalating issues relates
to the release team, but is already covered in the release-team
role handbooks and that escalation process is good to have visible
to developers broadly so they understand that they're liable to be
pinged by the release team for clarifying information.

See also kubernetes/community#2430

Signed-off-by: Tim Pepper <[email protected]>
@tpepper
Copy link
Member Author

tpepper commented Jul 27, 2018

/assign @spiffxp

Copy link
Contributor

@guineveresaenger guineveresaenger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple of tweaks and a question. Thanks @tpepper!


The SIG owner label defines the SIG to which the bot will escalate if the issue is not resolved
or updated by the deadline. If there are no updates after escalation, the
issue may automatically removed from the milestone.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"automatically be removed"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

- `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
- will automatically be moved out of the release milestone at code freeze
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it appears the bot removes these out of the milestone after 4 days - should that be mentioned here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added

```
**Action required**: This issue must have the `status/approved-for-milestone` label applied
by a SIG maintainer.
```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see comment above - milestone/needs approval has a really short turnaround (4 days?) before the issue gets kicked out of the milestone.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two lines just above this it notes if required labels are not applied within 3 days, the bot will remove. But I think that's 4 unless I'm reading the wrong yaml config line.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

found it...mungegithub/mungers/milestone-maintainer.go has RegisterOptions() has the set of default intervals.

Escalate to SIG and contributor through all available channels.
kind/bug: Fixes a bug.
```
- **If the approved label is not applied within 7 days of the `milestone/needs-approval` label being applied, the bot will move the issue out of the milestone and apply the `milestone/removed` label (unless the issue is critical-urgent).**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it is only 4 days.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

milestoneOptApprovalGracePeriod is 168*time.Hour or seven days. "The grace period to wait before removing a non-blocking issue/pr without sig approval from the active milestone."


Some issues are filed in repos outside the [kubernetes repo]. The bot must also be run against these
repos and follow the same pattern. The release team can query issues across repos in the kubernetes org using
a query like [this](https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+milestone%3Av1.7+org%3Akubernetes+)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's update sample link to a more recent version

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tweaked to 1.12


it must also include:

- a link to the repo with a query for issues in the milestone. See [this](https://github.com/kubernetes/kubectl/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20milestone%3Av1.7) example.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use 1.11 or 1.12 as example

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tweaked to 1.12

@spiffxp
Copy link
Member

spiffxp commented Jul 31, 2018

I'm pretty sure issues.md was pulled over into sig-release because it was very k/k-release-process-hygiene-specific. I would examine parity with with the issue triage role's handbook. And suggest a re-write to be agnostic to the release process first, if it's going to live here.

ie: outside of kubernetes release world, we require sig/foo for all issues, but people aren't restricted to just one of kind/bug kind/cleanup kind/feature

@guineveresaenger
Copy link
Contributor

It does feel like it should be made very clear that this is a release process specific doc that mainly explains the release-team's actions for the curious.

As such, it should have "release" in the title somewhere.

@tpepper
Copy link
Member Author

tpepper commented Jul 31, 2018

I feel like it's off in the corner in k/sig-release and is not just release-team actions. Release team observes the results of what all developers do. I read the doc as-is today as more focused on how a developer signals that an issue or PR is targeted to a release milestone, and once establishing it, how they keep it there in the face of a bot and release team who might remove it. I feel like only from "Escalation" section to the end is release-team specific.

@tpepper
Copy link
Member Author

tpepper commented Jul 31, 2018

I'll try to do some scrubbing versus issue triage and features handbooks in k/sig-release, and link from the proposed k/community/contributors/devel/issues.md to more detailed info on the release process there.

tpepper pushed a commit to tpepper/test-infra that referenced this pull request Jul 31, 2018
The documentation on how a developer gets code into a milestone release
is proposed to move in kubernetes/community#2430
and would require an associated update of the url the milestone munger
uses as a reference in its information GitHub comments.

Signed-off-by: Tim Pepper <[email protected]>
tpepper pushed a commit to tpepper/sig-release that referenced this pull request Jul 31, 2018
This document describes how the community targets issues and PRs
to a milestone release.  As such I think it fits best in the developer
guide.  A portion of the information on escalating issues relates
to the release team, but is already covered in the release-team
role handbooks and that escalation process is good to have visible
to developers broadly so they understand that they're liable to be
pinged by the release team for clarifying information.

See also kubernetes/community#2430

Signed-off-by: Tim Pepper <[email protected]>
@tpepper
Copy link
Member Author

tpepper commented Jul 31, 2018

Re: #2430 (comment) the title does say:

Targeting issues and PRs to release milestones

I see this as more than informational to the curious and that's why I'm proposing it for the developer guide. It's how developers get their work into milestones properly, with the release team and the bot and SIG leads helping on risk management and insuring the appropriate level of documentation and tests are also present.

The sig-release repo has a set of old documentation looking for a
better home.  The issues.md document there describes how a developer
targets an issue (or PR) to a milestone release.  This logically
fits better in the community/contributors/devel/ guide, so this commit
brings it in and a parallel commit will remove it from the other repo.

Signed-off-by: Tim Pepper <[email protected]>
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: spiffxp

If they are not already assigned, you can assign the PR to them by writing /assign @spiffxp in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@tpepper tpepper mentioned this pull request Jul 31, 2018
@tpepper tpepper changed the title contrib & devel guide: pull in issue doc from sig-release/ephemera [WIP] contrib & devel guide: pull in issue doc from sig-release/ephemera Aug 1, 2018
@k8s-ci-robot k8s-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Aug 1, 2018
@tpepper
Copy link
Member Author

tpepper commented Aug 1, 2018

/hold

Assuming no milestone munger, this doc needs a lot of rework.

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 1, 2018
@tpepper
Copy link
Member Author

tpepper commented Aug 20, 2018

Will replace differently based on base weeks' discussions in slack and release meetings.

@tpepper tpepper closed this Aug 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/contributor-guide Issues or PRs related to the contributor guide cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. sig/contributor-experience Categorizes an issue or PR as relevant to SIG Contributor Experience. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants