Re: Reconsidering the "github issue per PR" requirement

[Erick Fejta]

I am in favor of this change. I also like Joe (spxtr)'s proposal in the original discussion -- require a linked issue on PRs with a release note. Any appetite for making that change?

I can image recent release teams would be the primary beneficiaries. Dawn, Wojciech, Jaice, Joe, Anthony, Mehdy (managers for 1.7-1.9): any feedback or comments?

+kubernetes-sig-release 

On Fri, Jan 19, 2018 at 9:07 PM Clayton Coleman <smarter...@gmail.com> wrote:

I’ve noticed this same pattern - specifically around approval.  The linked issue requirement seems to create more work for me as an approver, since a sufficiently described PR can capture everything the issue can, and as an approver asking another contributor to open an issue when they’ve already captured sufficient justification for the change wastes both of our time.

Are we using the list of linked issues in a meaningful way?

--
You received this message because you are subscribed to the Google Groups "kubernetes-wg-contribex" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-con...@googlegroups.com.
To post to this group, send email to kubernetes-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/f9b7050d-a719-450c-bba2-4898e839228a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Wojciech Tyczynski]

 I completely agree with Clayton that requiring an issue for each PR is waste of time (in fact I was against introducing it from the beginning).

 Requiring an issue just for PRs with release note would definitely be better. But in many cases, I'm also not convinced it's really needed.

We generally want to have release-note for all cherrypicks, and for many of them 1 or 2 line description in the PR is enough in my opinion.

 thanks

wojtek

On Sat, Jan 20, 2018 at 9:22 AM, 'Erick Fejta' via kubernetes-sig-release <kubernetes-...@googlegroups.com> wrote:

I am in favor of this change. I also like Joe (spxtr)'s proposal in the original discussion -- require a linked issue on PRs with a release note. Any appetite for making that change?

I can image recent release teams would be the primary beneficiaries. Dawn, Wojciech, Jaice, Joe, Anthony, Mehdy (managers for 1.7-1.9): any feedback or comments?

+kubernetes-sig-release 

On Fri, Jan 19, 2018 at 9:07 PM Clayton Coleman <smarter...@gmail.com> wrote:

I’ve noticed this same pattern - specifically around approval.  The linked issue requirement seems to create more work for me as an approver, since a sufficiently described PR can capture everything the issue can, and as an approver asking another contributor to open an issue when they’ve already captured sufficient justification for the change wastes both of our time.

Are we using the list of linked issues in a meaningful way?

--
You received this message because you are subscribed to the Google Groups "kubernetes-wg-contribex" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-contribex+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-wg-contribex@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/f9b7050d-a719-450c-bba2-4898e839228a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-release+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-release@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-release/CAMMDcuFWC%2BABE7vHhQ-pvyHiEkjsuZP8XJdAsQAOwF19U3SE7A%40mail.gmail.com.

[Jordan Liggitt]

> require a linked issue on PRs with a release note. Any appetite for making that change?

That seems like it would motivate people to not write release notes.

[Jordan Liggitt]

As much as I love chatting with the bot, if it's optional, I'd rather
see this be opt in, and work on reviewer/approver education about what
should be in a PR before it gets approved (good description,
motivation for change, etc).

If there are things collecting PR -> issue links and making use of
them, I haven't seen them (and if they did exist, I suspect they could
work equally well off of just PR descriptions/release-note snippets)



> On Jan 20, 2018, at 12:53 PM, Christoph Blecker <cble...@gmail.com> wrote:
>
> The other option, if there is still value to it, would be allowing the reviewer (effectively any org member) to bypass the requirement, rather than only allowing an approver to do so. This would still allow for the collection/requirement of this information, but allow a wider pool of people to triage and get PRs merged.

[Aaron Crickenberger]

Thanks Jordan.  I am also in favor of disabling this requirement entirely.  I personally haven't seen any value from it, let alone enough to offset the friction it introduces.

Issue/PR links aren't a first class citizen as far as GitHub's API is concerned so tools that make use of this sort of info haven't spontaneously appeared.  There was an effort to put together https://github.com/kubernetes/release/tree/master/toolbox/relnotes but I'm not sure that it's really gone anywhere.

- aaron

--
You received this message because you are subscribed to the Google Groups "kubernetes-wg-contribex" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-contribex+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-wg-contribex@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/CALbx6sYVYErRXMi8ccD%2BQ0i6HrU_SF%3Dvqw0pFRScps%2B2Yzj%2BAw%40mail.gmail.com.

[Christoph Blecker]

Opened https://github.com/kubernetes/test-infra/pull/6373 to enact this.

Shall we set Friday for lazy consensus?

Cheers,

Christoph

On 22 January 2018 at 10:10, Aaron Crickenberger <aaron.cri...@gmail.com> wrote:

Thanks Jordan.  I am also in favor of disabling this requirement entirely.  I personally haven't seen any value from it, let alone enough to offset the friction it introduces.

Issue/PR links aren't a first class citizen as far as GitHub's API is concerned so tools that make use of this sort of info haven't spontaneously appeared.  There was an effort to put together https://github.com/kubernetes/release/tree/master/toolbox/relnotes but I'm not sure that it's really gone anywhere.

- aaron

On Sat, Jan 20, 2018 at 10:58 AM, Jordan Liggitt <jlig...@redhat.com> wrote:

As much as I love chatting with the bot, if it's optional, I'd rather
see this be opt in, and work on reviewer/approver education about what
should be in a PR before it gets approved (good description,
motivation for change, etc).

If there are things collecting PR -> issue links and making use of
them, I haven't seen them (and if they did exist, I suspect they could
work equally well off of just PR descriptions/release-note snippets)



> On Jan 20, 2018, at 12:53 PM, Christoph Blecker <cble...@gmail.com> wrote:
>
> The other option, if there is still value to it, would be allowing the reviewer (effectively any org member) to bypass the requirement, rather than only allowing an approver to do so. This would still allow for the collection/requirement of this information, but allow a wider pool of people to triage and get PRs merged.

--
You received this message because you are subscribed to the Google Groups "kubernetes-wg-contribex" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-contribex+unsubscr...@googlegroups.com.

To post to this group, send email to kubernetes-wg-contribex@googlegroups.com.

[Davanum Srinivas]

I support this!

Thanks,
Dims

>>> email to kubernetes-wg-con...@googlegroups.com.

>>> To post to this group, send email to

>>> kubernetes-...@googlegroups.com.

>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/kubernetes-wg-contribex/CALbx6sYVYErRXMi8ccD%2BQ0i6HrU_SF%3Dvqw0pFRScps%2B2Yzj%2BAw%40mail.gmail.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>

> --
> You received this message because you are subscribed to the Google Groups
> "kubernetes-wg-contribex" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to kubernetes-wg-con...@googlegroups.com.

> To post to this group, send email to

> kubernetes-...@googlegroups.com.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/kubernetes-wg-contribex/CADx2oGEonB6mwqWgAJo2uRdpjwFrWPV6-ww7WfQAc%3DZgBoYyjg%40mail.gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.

--
Davanum Srinivas :: https://twitter.com/dims

[Benjamin Elder]

FWIW as an aside see this thread for why "fixes #1234" can be bad https://github.com/kubernetes/test-infra/issues/5032#issuecomment-337689062 and this one for an extreme example https://github.com/kubernetes/features/issues/383#event-1358265990

:/

On Sat, Jan 20, 2018, 09:54 Christoph Blecker <cble...@gmail.com> wrote:

I am in favour of removing the requirement completely, barring any large objections from the release team. It doesn't stop people from putting associated issues or "fixes #12345" in the PR body, as it's still a part of the PR template.

The other option, if there is still value to it, would be allowing the reviewer (effectively any org member) to bypass the requirement, rather than only allowing an approver to do so. This would still allow for the collection/requirement of this information, but allow a wider pool of people to triage and get PRs merged.

Cheers,

Christoph

On 20 January 2018 at 07:05, Jordan Liggitt <jlig...@redhat.com> wrote:

> require a linked issue on PRs with a release note. Any appetite for making that change?

That seems like it would motivate people to not write release notes.

--
You received this message because you are subscribed to the Google Groups "kubernetes-wg-contribex" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-con...@googlegroups.com.
To post to this group, send email to kubernetes-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/CALbx6sbn8jf7rOce_wwesHoLdDkKphH_RLn6jGm2azsBNz6h2w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "kubernetes-wg-contribex" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-con...@googlegroups.com.
To post to this group, send email to kubernetes-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/CADx2oGGfoLmKMUPHMa8BR3Kd_EPoucaEPsZBgka%2B2qQgmxpE4w%40mail.gmail.com.

[Josh Berkus]

All,

My $0.02:

I *have* been working on a tool which tracks issue/PR links. However, I
have not been relying on the "Fixes: #####" because that's rarely
honored in PRs; there are many PRs with no issue at all, and there are
also PRs which fix issues by don't have the Fixes tag. I'd say that
this "requirement" is honored only about 1/3 of the time.

I would *love* to have a reliable way to link a PR to an issue that that
PR is expected to fulfill, and I don't care what that method is. The
current "fixes" requirement isn't it, so it can go AFAIC.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSAS

[Jordan Liggitt]

Hearing no objections and plenty of agreement, I move we merge https://github.com/kubernetes/test-infra/pull/6373

[Christoph Blecker]

Seconded!

[Wojciech Tyczynski]

+1

[Christoph Blecker]

Motion carried: https://github.com/kubernetes/test-infra/pull/6373#issuecomment-360850429

This should take effect pretty much immediately as it's just a plugin config setting.