self-lgtm + rebase

[Brendan Burns]

Hey Folks,

I recently had a PR: https://github.com/kubernetes/kubernetes/pull/39223 that I had an LGTM on, but I needed to rebase. I rebased, so of course I lost my LGTM, so I did a self-LGTM, but the robot now rejects self-LGTM.

Now in general, rejecting self-LGTM sounds like a good idea to me, but in this case, it delays the merging of the PR (Eric Paris was gracious enough to LGTM it later that day)

But it seems to me that we need some additional flexibility here to reduce load on reviewers who are basically just rubber stamping rebase changes anyway...

I don't know what the right answer here is ('/lgtm-no-changes')?

But regardless, it feels like there is some improvement that could be done in the bot to be more flexible about self-lgtm.

Thoughts?

--brendan

[Brian Grant]

We've discussed a "sticky" LGTM, so that a reviewer could respond the equivalent "LGTM after you make these changes", "LGTM, please squash", "LGTM, please rebase", etc. Or we could just not remove LGTM automatically in some cases, such as when the PR author is trusted (e.g., a reviewer, approver, maintainer, etc.).

Someone would need to implement it. :-)

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/0f36389f-584a-4ea4-b3fb-2e5028d9a0ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brian Grant]

+Contributor experience

On Thu, Jan 26, 2017 at 9:51 PM, Brian Grant <brian...@google.com> wrote:

We've discussed a "sticky" LGTM, so that a reviewer could respond the equivalent "LGTM after you make these changes", "LGTM, please squash", "LGTM, please rebase", etc. Or we could just not remove LGTM automatically in some cases, such as when the PR author is trusted (e.g., a reviewer, approver, maintainer, etc.).

Someone would need to implement it. :-)

On Thu, Jan 26, 2017 at 9:39 PM, Brendan Burns <brendan...@gmail.com> wrote:

Hey Folks,

I recently had a PR: https://github.com/kubernetes/kubernetes/pull/39223 that I had an LGTM on, but I needed to rebase. I rebased, so of course I lost my LGTM, so I did a self-LGTM, but the robot now rejects self-LGTM.

Now in general, rejecting self-LGTM sounds like a good idea to me, but in this case, it delays the merging of the PR (Eric Paris was gracious enough to LGTM it later that day)

But it seems to me that we need some additional flexibility here to reduce load on reviewers who are basically just rubber stamping rebase changes anyway...

I don't know what the right answer here is ('/lgtm-no-changes')?

But regardless, it feels like there is some improvement that could be done in the bot to be more flexible about self-lgtm.

Thoughts?

--brendan

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.

To post to this group, send email to kuberne...@googlegroups.com.

[Tim Hockin]

yeah, self-lgtm after rebase is pretty common, in my experience.

On Thu, Jan 26, 2017 at 9:51 PM, 'Brian Grant' via Kubernetes
developer/contributor discussion <kuberne...@googlegroups.com>
wrote:

>>> email to kubernetes-de...@googlegroups.com.

>>> To post to this group, send email to kuberne...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/kubernetes-dev/0f36389f-584a-4ea4-b3fb-2e5028d9a0ad%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 developer/contributor discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to kubernetes-de...@googlegroups.com.

> To post to this group, send email to kuberne...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/kubernetes-dev/CAKCBhs75aC7pY5MvX0rVhSAggTdu0ccmHVg%3DU5xpmFndJmFcHg%40mail.gmail.com.

[Jordan Liggitt]

That seems perfectly reasonable for PR authors who have labeling power but honored the intent of review/approve, and are just rebasing, not changing what was originally reviewed/approved.

Finding a way to extend that ability to other trusted authors will quickly become necessary, especially now that approvers can mean hunting down 2-4 retags after a rebase.

On Fri, Jan 27, 2017 at 12:52 AM, 'Tim Hockin' via kubernetes-wg-contribex <kubernetes-...@googlegroups.com> wrote:

yeah, self-lgtm after rebase is pretty common, in my experience.

On Thu, Jan 26, 2017 at 9:51 PM, 'Brian Grant' via Kubernetes

developer/contributor discussion <kubernetes-dev@googlegroups.com>
wrote:

>>> email to kubernetes-dev+unsubscribe@googlegroups.com.
>>> To post to this group, send email to kubernetes-dev@googlegroups.com.

>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/kubernetes-dev/0f36389f-584a-4ea4-b3fb-2e5028d9a0ad%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 developer/contributor discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to kubernetes-dev+unsubscribe@googlegroups.com.
> To post to this group, send email to kubernetes-dev@googlegroups.com.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kubernetes-dev/CAKCBhs75aC7pY5MvX0rVhSAggTdu0ccmHVg%3DU5xpmFndJmFcHg%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-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/CAO_Rewa2Ez8YHBCzZ5QE9cvsXZHPefdbWXBNx99i0t%3DjpY6vog%40mail.gmail.com.

[Brendan Burns]

Can I self-lgtm via label? (I can set the label, but does the bot rip that off too?, I guess I can try :)

If we settle on an accepted mechanism and syntax, I'm happy to implement it.

--brendan

On Thu, Jan 26, 2017 at 10:16 PM Jordan Liggitt <jlig...@redhat.com> wrote:

That seems perfectly reasonable for PR authors who have labeling power but honored the intent of review/approve, and are just rebasing, not changing what was originally reviewed/approved.

Finding a way to extend that ability to other trusted authors will quickly become necessary, especially now that approvers can mean hunting down 2-4 retags after a rebase.

On Fri, Jan 27, 2017 at 12:52 AM, 'Tim Hockin' via kubernetes-wg-contribex <kubernetes-...@googlegroups.com> wrote:

yeah, self-lgtm after rebase is pretty common, in my experience.

On Thu, Jan 26, 2017 at 9:51 PM, 'Brian Grant' via Kubernetes

developer/contributor discussion <kuberne...@googlegroups.com>
wrote:

>>> email to kubernetes-de...@googlegroups.com.
>>> To post to this group, send email to kuberne...@googlegroups.com.

>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/kubernetes-dev/0f36389f-584a-4ea4-b3fb-2e5028d9a0ad%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 developer/contributor discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to kubernetes-de...@googlegroups.com.
> To post to this group, send email to kuberne...@googlegroups.com.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kubernetes-dev/CAKCBhs75aC7pY5MvX0rVhSAggTdu0ccmHVg%3DU5xpmFndJmFcHg%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/CAO_Rewa2Ez8YHBCzZ5QE9cvsXZHPefdbWXBNx99i0t%3DjpY6vog%40mail.gmail.com.

[Brian Grant]

On Thu, Jan 26, 2017 at 10:43 PM, Brendan Burns <brendan...@gmail.com> wrote:

Can I self-lgtm via label? (I can set the label, but does the bot rip that off too?, I guess I can try :)

If we settle on an accepted mechanism and syntax, I'm happy to implement it.

Thanks.

"/lgtm-no-changes" sounds to me like changes shouldn't be allowed.

I couldn't think of any relatively short phrases that wouldn't be ambiguous, so how about another acronym, such as /plgtm, for Permanent LGTM, or /slgtm, for Sticky LGTM?

 

--brendan

On Thu, Jan 26, 2017 at 10:16 PM Jordan Liggitt <jlig...@redhat.com> wrote:

That seems perfectly reasonable for PR authors who have labeling power but honored the intent of review/approve, and are just rebasing, not changing what was originally reviewed/approved.

Finding a way to extend that ability to other trusted authors will quickly become necessary, especially now that approvers can mean hunting down 2-4 retags after a rebase.

On Fri, Jan 27, 2017 at 12:52 AM, 'Tim Hockin' via kubernetes-wg-contribex <kubernetes-wg-contribex@googlegroups.com> wrote:

yeah, self-lgtm after rebase is pretty common, in my experience.

On Thu, Jan 26, 2017 at 9:51 PM, 'Brian Grant' via Kubernetes

developer/contributor discussion <kubernetes-dev@googlegroups.com>
wrote:

>>> email to kubernetes-dev+unsubscribe@googlegroups.com.
>>> To post to this group, send email to kubernetes-dev@googlegroups.com.

>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/kubernetes-dev/0f36389f-584a-4ea4-b3fb-2e5028d9a0ad%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 developer/contributor discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to kubernetes-dev+unsubscribe@googlegroups.com.
> To post to this group, send email to kubernetes-dev@googlegroups.com.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kubernetes-dev/CAKCBhs75aC7pY5MvX0rVhSAggTdu0ccmHVg%3DU5xpmFndJmFcHg%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-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/CAO_Rewa2Ez8YHBCzZ5QE9cvsXZHPefdbWXBNx99i0t%3DjpY6vog%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-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/CAOgwWTumosytRoK_kcpussO2-ADAAyDFF1YMvg2JB49TAHwCmQ%40mail.gmail.com.

[Andy Goldstein]

What if the robot allowed self-lgtms if someone else had previously lgtm'd?

--brendan

>>> To post to this group, send email to kuberne...@googlegroups.com.

>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/kubernetes-dev/0f36389f-584a-4ea4-b3fb-2e5028d9a0ad%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 developer/contributor discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-dev+unsubscribe@googlegroups.com.

> To post to this group, send email to kuberne...@googlegroups.com.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kubernetes-dev/CAKCBhs75aC7pY5MvX0rVhSAggTdu0ccmHVg%3DU5xpmFndJmFcHg%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-contribex+unsubscr...@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/CAO_Rewa2Ez8YHBCzZ5QE9cvsXZHPefdbWXBNx99i0t%3DjpY6vog%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-contribex+unsubscr...@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/CAOgwWTumosytRoK_kcpussO2-ADAAyDFF1YMvg2JB49TAHwCmQ%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 developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAKCBhs5e2zo4x_s-dpjB0rMoHhgo9aXuHRMfFLRTV4B0pO1Jyg%40mail.gmail.com.

[Brian Grant]

On Fri, Jan 27, 2017 at 8:37 AM, Andy Goldstein <agol...@redhat.com> wrote:

What if the robot allowed self-lgtms if someone else had previously lgtm'd?

I'm not opposed to that, but if we're relying on the honor system anyway, it would be one less step to just not have to add back the lgtm. If the author decided to make more significant changes and wanted re-review, they could remove lgtm and ping the reviewer.

Another thing to fix: No notification is sent to the author (or to the reviewer, either) when lgtm is removed, so PRs can get stuck without anyone noticing.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAKCBhs5e2zo4x_s-dpjB0rMoHhgo9aXuHRMfFLRTV4B0pO1Jyg%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-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/CAJFkcLKy3YE_Hp%3Dz7zHHQC3bbbEwqgqLS%2Be6swfHwZsA%2BHVQPA%40mail.gmail.com.

[Andy Goldstein]

On Fri, Jan 27, 2017 at 11:41 AM, 'Brian Grant' via Kubernetes developer/contributor discussion <kuberne...@googlegroups.com> wrote:

On Fri, Jan 27, 2017 at 8:37 AM, Andy Goldstein <agol...@redhat.com> wrote:

What if the robot allowed self-lgtms if someone else had previously lgtm'd?

I'm not opposed to that, but if we're relying on the honor system anyway, it would be one less step to just not have to add back the lgtm. If the author decided to make more significant changes and wanted re-review, they could remove lgtm and ping the reviewer.

So why not just make this the default; i.e., lgtm is permanent, the bot never removes it, and it's up to the PR author to remove it if needed?

 

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-contribex/CAJFkcLKy3YE_Hp%3Dz7zHHQC3bbbEwqgqLS%2Be6swfHwZsA%2BHVQPA%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 developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.

To post to this group, send email to kubernetes-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAKCBhs5cWp2K4ODXx7_5umsK24QCGEbjEJ5xccpK59KzM2hZEQ%40mail.gmail.com.

[Brian Grant]

On Fri, Jan 27, 2017 at 8:43 AM, Andy Goldstein <agol...@redhat.com> wrote:

On Fri, Jan 27, 2017 at 11:41 AM, 'Brian Grant' via Kubernetes developer/contributor discussion <kubernetes-dev@googlegroups.com> wrote:

On Fri, Jan 27, 2017 at 8:37 AM, Andy Goldstein <agol...@redhat.com> wrote:

What if the robot allowed self-lgtms if someone else had previously lgtm'd?

I'm not opposed to that, but if we're relying on the honor system anyway, it would be one less step to just not have to add back the lgtm. If the author decided to make more significant changes and wanted re-review, they could remove lgtm and ping the reviewer.

So why not just make this the default; i.e., lgtm is permanent, the bot never removes it, and it's up to the PR author to remove it if needed?

I'd be fine with that for "trusted" authors, however we define that.

 

 

[Jordan Liggitt]

I'd prefer this for trusted authors, rather than developing "self-lgtm" muscle memory. 

Need to make it clear how an author without label rights adds do-not-merge or cancels lgtm if they need to request additional review

[Clayton Coleman]

I do think that we are on the honor system - mistakes, accidents, and small abuses will happen, and we need the human processes to deal with those anyway.  Over optimizing the machine process might not be required.  

Rule of thumb is that anyone who sticks LGTM on an issue is responsible for that issue doing the right thing, and I have seen a very low % of abuse of the self lgtm mechanism across contributors.  I kind of expect maintainers to be able to self-lgtm and be answerable to their own conscience and others that they are not abusing the system, and that we do what we can to keep an eye on it.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAKCBhs5cWp2K4ODXx7_5umsK24QCGEbjEJ5xccpK59KzM2hZEQ%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 developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/-5215612718781068146%40unknownmsgid.

[Daniel Smith]

What about a trust-but-verify version of LGTM? So I tell the bot /lgtm-hard and then, after it has been through N rebase cycles and merged, the bot pings me "this merged, please double check that it's what you expected" (only needs to be said if N > 0). This would save me SO MUCH TIME and give PR authors a much better experience. We could even automatically do this when the PR author is (say) an org member, or after they have 5 commits and we're pretty sure they're not going to e.g. accidentally push commits from the wrong branch...

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/-5215612718781068146%40unknownmsgid.

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

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAH16Sh%2B5-kpw50F609WNhPxYadHDF_pdQO24PxXprPeRGcvP7w%40mail.gmail.com.

[Michael Taufen]

+ 1 "This merged after your LGTM, but with changes." It would be really cool if the notification contained a diff between your LGTM'd version and the merged version.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAH16Sh%2B5-kpw50F609WNhPxYadHDF_pdQO24PxXprPeRGcvP7w%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 developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAB_J3bYpSWpmaho1uW7cKCiOVYwj1jsasO-gDoHk0D_mzWmHmg%40mail.gmail.com.

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

--

Michael Taufen

MTV SWE

[Antoine Pelisse]

Orthogonal issue: Sticky approval after rebase. https://github.com/kubernetes/test-infra/issues/1743.

[Brendan Burns]

Ok, so there are two alternatives proposed:

1) /lgtm-hard - which the reviewer issues and which overrides the self-lgtm rule? 

2) revert the anti-lgtm bot for a set of "trusted" authors (likely OWNERS)

And, regardless of which of the two we choose, we will implement a "btw, this was merged with changes" note.  We'll try to get the diff, but I'm not positive how easy it is to get the diff from github if the commit has changed.

So can we have a show of hands for #1 or #2 above?

Thanks

--brendan

[Tim Hockin]

2.  Less syntax more better

[Michael Taufen]

Reviewable seems to be able to track across changes to the PR as a whole, and IIRC we at least track first LGTM time as a merge queue tiebreaker, so we should theoretically be able to get a useful diff.

I vote (2). Prefer to avoid label proliferation if possible. 

If we still have to re-review rebases for non-OWNERS, having a diff since LGTM is even more useful.

--

You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/fdb4642a-b0f5-43ec-8f72-a43cef1e044c%40googlegroups.com.

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

[Brian Grant]

On Fri, Jan 27, 2017 at 9:02 PM, Tim Hockin <tho...@google.com> wrote:

2.  Less syntax more better

+1.

[Brendan Burns]

sgtm, I'll send the PR for the bot, and post it to this thread as well.

--brendan

[Erick Fejta]

Thanks so much Brendan!

I filed test-infra#1755 to track this and assigned it to you. If/when you need to prioritize other things I also think this will make a great task for someone in +kubernetes-wg-contribex.

--

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/3398460b-0f80-4ba6-84e1-fe5f2351d056%40googlegroups.com.

[Brian Grant]

On Sun, Jan 29, 2017 at 11:51 PM, 'Erick Fejta' via Kubernetes developer/contributor discussion <kuberne...@googlegroups.com> wrote:

Thanks so much Brendan!

+1

Everyone else: You don't have to be a founder of the project to help! :-)

If you look at a handful of PRs, I'd bet you could find a way to streamline the review process. 

For instance, I looked at one of the XS PRs (chosen essentially at random) and saw that someone was "fixing" a typo in a vendored file. We could add a check that those files are only updated from their origins. 

 

I filed test-infra#1755 to track this and assigned it to you. If/when you need to prioritize other things I also think this will make a great task for someone in +kubernetes-wg-contribex.

On Sun, Jan 29, 2017 at 2:50 PM Brendan Burns <brendan...@gmail.com> wrote:

sgtm, I'll send the PR for the bot, and post it to this thread as well.

--brendan

On Friday, January 27, 2017 at 9:23:54 PM UTC-8, Brian Grant wrote:

On Fri, Jan 27, 2017 at 9:02 PM, Tim Hockin <tho...@google.com> wrote:

2.  Less syntax more better

+1.

 

On Jan 27, 2017 8:14 PM, "Brendan Burns" <brendan...@gmail.com> wrote:

Ok, so there are two alternatives proposed:

1) /lgtm-hard - which the reviewer issues and which overrides the self-lgtm rule? 

2) revert the anti-lgtm bot for a set of "trusted" authors (likely OWNERS)

And, regardless of which of the two we choose, we will implement a "btw, this was merged with changes" note.  We'll try to get the diff, but I'm not positive how easy it is to get the diff from github if the commit has changed.

So can we have a show of hands for #1 or #2 above?

Thanks

--brendan

On Friday, January 27, 2017 at 8:02:23 PM UTC-8, Antoine Pelisse wrote:

Orthogonal issue: Sticky approval after rebase. https://github.com/kubernetes/test-infra/issues/1743.

--
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/3398460b-0f80-4ba6-84e1-fe5f2351d056%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 developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAMMDcuHMh5oSWrs1h5%3DiKPXvET61CP%2BbnQ-WWGn87e2a0seipQ%40mail.gmail.com.