Test-infra: mungegithub: no-issue: Is it possible to turn off the "no associated issue" munger through config?

[stevekuznetsov]

This munger does not always make sense for every repo and it would be cool if it could be disabled through config.

/area mungegthub

/cc @kargakis

[spiffxp]

FYI @kubernetes/sig-contributor-experience-misc @rmmh @cjwagner

/area mungegithub

[grodrigues3]

@apelisse

[fejta]

My preference would just be to delete this everywhere. I do not think it is helpful/useful, just irritating.

[lavalamp]

I tend to agree. /approve no-issue means that this is just annoying
rather than causing a behavior change.

On Wed, Jul 26, 2017 at 1:46 PM, Erick Fejta [e-mail]
wrote:

My preference would just be to delete this everywhere. I do not think it
is helpful/useful, just irritating.

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/test-infra/issues/3704#issuecomment-318177302,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAngloH7sKX3BK-4E9IbMePLAYOstY6Bks5sR6WygaJpZM4OkTAP
.

[cblecker]

@kubernetes/sig-release-misc Bringing in sig-release as I believe this was brought in via the 1.7 release team.

[grodrigues3]

Link to Relnotes Improvement Proposal

(note it's shared with k8s-dev)

Two things in support of the current mechanism:

• I really like the idea of being able to auto generate release notes on a per sig basis.
• And visibility into a release is only going to get more challenging as the number of contributors/PRs increases.

I don't want to disable it everywhere without out a replacement solution, but I think it makes sense to make it configurable.

[lavalamp]

I think it is great to aggregate PRs by issue in the case where multiple
PRs work together to solve an issue.

I think it is not great to require an issue for every PR, it is just
busywork for things like typo fixes etc.

On Wed, Jul 26, 2017 at 2:00 PM, grodrigues3 [e-mail]
wrote:

Link to Relnotes Improvement Proposal
https://docs.google.com/presentation/d/1f-Td0Fs1kR3rSWlYzR0EJ2PFgd8_R2srlE_O_vxwdlk/edit#slide=id.p

(note it's shared with k8s-dev)

Two things in support of the current mechanism:

• I really like the idea of being able to auto generate release notes
  on a per sig basis.
• And visibility into a release is only going to get more challenging
  as the number of contributors/PRs increases.

I don't want to disable it everywhere without out a replacement solution,
but I think it makes sense to make it configurable.

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/test-infra/issues/3704#issuecomment-318181127,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAngliHtdmpd6T3VxnjwHnbVToNQJ-Pkks5sR6jfgaJpZM4OkTAP
.

[yutongz]

Agree, not really useful to have "/approve no-issue"

[grodrigues3]

@jdumars @pwittrock @calebamiles (1.8 release team manager and sig-release leads)

This is a balance between getting better visibility into the release and velocity. Right now, our release note process is very painful. They are manually sharded into sigs and it's unclear which PRs are related and address the same issue.

Having related PRs reference the same issue would solve part of the problem and having every sig associated with an issue would allow us to automatically divide relnotes by sig.

Dawn's proposal uses the following example.

[stevekuznetsov]

Looks like the check is just hard-coded to look for issues under the k8s repo, as well, which means it's not super useful for any other user of the tool.

[calebamiles]

I recently read Russ Cox's fantastic article about the process of making a change to Go
and I feel that I have _personally failed_ to properly articulate the challenge that I
would like to solve as a person tangentially involved in the Kubernetes release process. In
my work I wear a couple of hats so I'll try and describe my various motivations and concerns
which may place this PR in a broader context.

In my capacity at CoreOS, I try to help communicate what is being worked on upstream so
that our wonderful marketing and communications teams can talk about all the amazing work
that goes into a Kubernetes release. I believe it would be very nice to be able to provide
high level summaries of ongoing or planned work which target a "C Level" understanding of
the project. As a recovering developer it would be a much easier task if there were high
quality documentation explaining the motivation and example usage for a proposed change to
Kubernetes that I could summarize without first. The inconsistency of the content found in
the Design proposal link section of the issues in kubernetes/features makes this
difficult to do across all SIGs and the One-line feature description section often
fails to capture the intent hammered out in private or out of band discussions among SIG
members or within their sponsoring organizations. I would love to have access to a
summary and motivation that I could summarize for our
teams. I would argue that for any established company the information contained in those
sections is known before work actually begins, my goal is to share this information more
broadly.

In my capacity as a member of a Kubernetes release team I am a little dispirited by how much
work is required to publish release notes. Again I believe that the _vast majority_ of the
information which _should_ go into a high quality release note is available before work
begins and it would be really nice to not have to wait until work begins, or is completed
in the case where release notes are attached to Pull Requests, to be able to generate a
roadmap, in my capacity as a member of SIG PM, which people interested in using
Kubernetes need in order to plan their consumption of the project or lobby their own
"C Level" internal sponsor that Kubernetes is the platform for their company. While all
reasonably organized Kubernetes vendors would have internal teams dedicated to producing
this material, I believe that as an open source community we should produce _authoritative_
information for the community.

In my personal experience over the last two Kubernetes releases it has taken 30 - 48
engineering hours to sort and edit the release notes which are automatically scraped by the
relnotes tool, thanks to the community for its creation and maintenance, and this is
simply unworkable given the volunteer staffing of the release teams. I believe that
Dawn's proposal is a great first step in laying out a process for collecting possibly
higher quality release notes, but I would also cation against the belief that automation is a
panacea for what are fundamentally process problems. It remains a challenge to design processes
and automation which reinforce each other but in the world of physical objects some companies
are rethinking their initial relentless drive towards automation...there are probably
lessons for us as well. I also agree that for "trivial" pull requests requiring an issue before
a PR can be merged is probably too much overhead. Given the vague definition of "substantial"
in our membership guidelines perhaps a reasonable compromise would be to require an
associated issue for any PR with a substantial label which we could also use to help us
ensure community members are progressing up the contributor ladder. Even absent any automation
to act on the label it could be useful to the release team and other interested parties tracking
our development progress. Anyway those are just my thoughts which I have tried to expand in
slightly less detail in a draft proposal to adopt something similar to the Rust RFC process
which I would love high level feedback on, which is why it's a GitHub Gist to avoid the line by
line concerns that I don't want to address before getting some agreement on the goals of a new
process.

[kargakis]

I am not sure that this is the right forum for discussing whether we should nuke "/approve no-issue" or not as it seems like a much larger topic than the intent of the present issue. We need to make the option configurable because it's not just the main k8s repo that is using the munger today but elsewhere we are locked down with it. I would suggest moving the on-going discussion in kubernetes-dev.

[spiffxp]

/close

discussed at latest sig-release meeting, if the linked PR doesn't fully address this issue, feel free to reopen

whether --approval-requires-issue should be turned off for kubernetes/kubernetes is a separate decision we couldn't make today, predicated mostly on whether someone is actually willing to implement something that consumes linked issues for release notes