Re: PR merge policy

On 4/29/17 15:51, Justin Mclean wrote: HI, Does anybody know if: 1. Any other Apache project has a similar forced-revert policy; and None that I’m aware of. But if a committer checks in some code the breaks something and someone vetoes it, it is expected that they revert the checkin and fix

Re: PR merge policy

HI, > Does anybody know if: > 1. Any other Apache project has a similar forced-revert policy; and None that I’m aware of. But if a committer checks in some code the breaks something and someone vetoes it, it is expected that they revert the checkin and fix it. I’ve seen this happen a few

Re: PR merge policy

e for fixing the situation by rolling back the commit and re-opening the PR for further review. IMO, committer right comes with the responsibility to respect the community and policies it established. I would disagree that rolling back should be used only in case of a disaster unless PR merge po

Re: PR merge policy

olling back the commit and re-opening the PR for further review. IMO, committer right comes with the responsibility to respect the community and policies it established. I would disagree that rolling back should be used only in case of a disaster unless PR merge policy violation is a disaster :-) (and i

Re: PR merge policy

cted the broader community, that they need to be cognizant of it and > >> be > >> more careful in the future. Also, I am against any public shaming of > >> individuals in the emails. > >> > >> Thanks > >> > >> On Fri, Apr 28, 2017 at 7:10 PM,

Re: PR merge policy

ion by rolling back the commit and re-opening the PR for further >>> review. IMO, committer right comes with the responsibility to respect the >>> community and policies it established. >>> >>> I would disagree that rolling back should be used only in case of a &

Re: PR merge policy

tributing.html. The vote clearly happened a week ago when I initially proposed that a PR can be merged only once the community has a chance to review it . http://apex.apache.org/contrib uting.html is for new contributors and new committers, existing committers should be fully aware of the PR mer

Re: PR merge policy

he commit and re-opening the PR for further review. IMO, committer right comes with the responsibility to respect the community and policies it established. I would disagree that rolling back should be used only in case of a disaster unless PR merge policy violation is a disaster :-) (and it actually

Re: PR merge policy

espect the community, so I >>> disagree that this is "just kicking the can down the road" as committer >>> right may be eventually revoked (hope we don't need to go that far ever). >>> >>> Not all policies are immediately reflected at >>> http://apex.

Re: PR merge policy

ed that a PR can be merged only once the community has a chance to review it . http://apex.apache.org/contrib uting.html is for new contributors and new committers, existing committers should be fully aware of the PR merge policy and if in doubt, raise a question here (dev@apex). We are all humans

Re: PR merge policy

ld disagree that rolling back should be used only in case of a > disaster unless PR merge policy violation is a disaster :-) (and it > actually is). > > Thank you, > > Vlad > > > On 4/28/17 14:21, Amol Kekre wrote: > >> Strongly agree with Ilya. Lets take

Re: PR merge policy

ote clearly happened a > week ago when I initially proposed that a PR can be merged only once the > community has a chance to review it . http://apex.apache.org/contrib > uting.html is for new contributors and new committers, existing > committers should be fully aware of the PR merge polic

Re: PR merge policy

to review it . http://apex.apache.org/contributing.html is for new contributors and new committers, existing committers should be fully aware of the PR merge policy and if in doubt, raise a question here (dev@apex). We are all humans and may overlook problems in PRs that we review. Th

Re: PR merge policy

tter right comes with the responsibility to respect the > > community and policies it established. > > > > I would disagree that rolling back should be used only in case of a > > disaster unless PR merge policy violation is a disaster :-) (and it > > actually is). &

Re: PR merge policy

*Reply-To: *"dev@apex.apache.org" <dev@apex.apache.org> *Date: *Friday, April 28, 2017 at 10:09 AM *To: *"dev@apex.apache.org" <dev@apex.apache.org> *Subject: *Re: PR merge policy On a lighter note, looks like the powers that be have been listening on this conversat

Re: PR merge policy

ter right comes with the responsibility to respect the > community and policies it established. > > I would disagree that rolling back should be used only in case of a > disaster unless PR merge policy violation is a disaster :-) (and it > actually is). > > Thank you, > > V

Re: PR merge policy

should be used only in case of a disaster unless PR merge policy violation is a disaster :-) (and it actually is). Thank you, Vlad On 4/28/17 14:21, Amol Kekre wrote: Strongly agree with Ilya. Lets take these events as learning opportunities for folks to learn and improve. There can always

Re: PR merge policy

t; > > > - Ilya Ganelin > > [image: id:image001.png@01D1F7A4.F3D42980] > > > > *From: *Pramod Immaneni <pra...@datatorrent.com> > *Reply-To: *"dev@apex.apache.org" <dev@apex.apache.org> > *Date: *Friday, April 28, 2017 at 10:09 AM > *To: *&q

Re: PR merge policy

e.org> Date: Friday, April 28, 2017 at 10:09 AM To: "dev@apex.apache.org" <dev@apex.apache.org> Subject: Re: PR merge policy On a lighter note, looks like the powers that be have been listening on this conversation and decided to force push an empty repo or maybe github just

Re: PR merge policy

se please propose how to deal with PR merge policy violations in > the future. I will -1 proposal to commit an improvement on top of a commit. > > Thank you, > > Vlad > > > On 4/27/17 21:48, Pramod Immaneni wrote: > >> I am sorry but I am -1 on the force push in th

Re: PR merge policy

In this case please propose how to deal with PR merge policy violations in the future. I will -1 proposal to commit an improvement on top of a commit. Thank you, Vlad On 4/27/17 21:48, Pramod Immaneni wrote: I am sorry but I am -1 on the force push in this case. On Apr 27, 2017, at 9:27

Re: PR merge policy

why not focus on what the committer should do? Development process >>>>>>> and >>>>>>> guidelines are there for a reason, and the issue was raised before. >>>>>>> >>>>>>> In this specific case, there is a string

Re: PR merge policy

e release. >>>>> >>>>> Thomas >>>>> >>>>> >>>>> On Thu, Apr 27, 2017 at 8:11 PM, Munagala Ramanath <r...@datatorrent.com >>>>>> >>>>> wrote: >>>>> >>>>> I agr

Re: PR merge policy

the issue was raised before. >>>>>> >>>>>> In this specific case, there is a string of commits related to the >>>>>> plugin >>>>>> feature that IMO should be part of the original review. There wasn't >>>>>> any

Re: PR merge policy

> any > >>>> need to rush this, the change wasn't important for the release. > >>>> > >>>> Thomas > >>>> > >>>> > >>>> On Thu, Apr 27, 2017 at 8:11 PM, Munagala Ramanath < > r...@datatorrent.com

Re: PR merge policy

an improvement on top ? Ram On Thu, Apr 27, 2017 at 7:55 PM, Vlad Rozov <v.ro...@datatorrent.com> wrote: Violation of the PR merge policy is a sufficient reason to forcibly undo the commit and such violations affect everyone in the community. Thank you, Vlad On 4/27/17 19:36, Pramod Immane

Re: PR merge policy

gt;>> >>>> Thomas >>>> >>>> >>>> On Thu, Apr 27, 2017 at 8:11 PM, Munagala Ramanath <r...@datatorrent.com >>>> > >>>> wrote: >>>> >>>> I agree with Pramod that force pushing should

Re: PR merge policy

gt;>> tracking of contributions. > > > > > >>>>>>> > > > > > >>>>>>> Either have separate commits or have one author. > > > > > >>>>>>> > > > > > >>>>>>> Thanks > > > > &

Re: PR merge policy

to undo something serious. Doing it just for a policy violation should itself be codified in our policies as a policy violation. Why not just commit an improvement on top ? Ram On Thu, Apr 27, 2017 at 7:55 PM, Vlad Rozov <v.ro...@datatorrent.com> wrote: Violation of the PR merge polic

Re: PR merge policy

o something serious. Doing it just for a policy violation > > > should > > > > itself be codified in our > > > > policies as a policy violation. > > > > > > > > Why not just commit an improvement on top ? > > > > > > > > Ram > &g

Re: PR merge policy

odified in our > > > policies as a policy violation. > > > > > > Why not just commit an improvement on top ? > > > > > > Ram > > > > > > On Thu, Apr 27, 2017 at 7:55 PM, Vlad Rozov <v.ro...@datatorrent.com> > > > wrote: >

Re: PR merge policy

licies as a policy violation. > > > > Why not just commit an improvement on top ? > > > > Ram > > > > On Thu, Apr 27, 2017 at 7:55 PM, Vlad Rozov <v.ro...@datatorrent.com> > > wrote: > > > > > Violation of the PR merge policy is a sufficient reason to

Re: PR merge policy

r 27, 2017 at 7:55 PM, Vlad Rozov <v.ro...@datatorrent.com> > wrote: > > > Violation of the PR merge policy is a sufficient reason to forcibly undo > > the commit and such violations affect everyone in the community. > > > > Thank you, > > > > Vlad > > > &

Re: PR merge policy

, 2017 at 7:55 PM, Vlad Rozov <v.ro...@datatorrent.com> wrote: > Violation of the PR merge policy is a sufficient reason to forcibly undo > the commit and such violations affect everyone in the community. > > Thank you, > > Vlad > > On 4/27/17 19:36, Pramod Immanen

Re: PR merge policy

Violation of the PR merge policy is a sufficient reason to forcibly undo the commit and such violations affect everyone in the community. Thank you, Vlad On 4/27/17 19:36, Pramod Immaneni wrote: I agree that PRs should not be merged without a chance for others to review. I don't agree

Re: PR merge policy

Rozov < >>>>>>> >>>>>> v.ro...@datatorrent.com >>> >>>> wrote: >>>>>>> >>>>>>> Pramod, >>>>>>>> >>>>>>>> No, it is not a request to update the apex.ap

Re: PR merge policy

(not just the main reviewer) as long as there are no objections from others. In that case, I am fine with it. On Thu, Apr 27, 2017 at 7:44 AM, Vlad Rozov < v.ro...@datatorrent.com> wrote: This is a friendly reminder regarding PR merge policy. Thank you, Vlad On 3/23/17 12:58, Vlad Rozov

Re: PR merge policy

gt; > On 4/27/17 08:05, Pramod Immaneni wrote: > > > > > > > > > >> Vlad, are you asking for a consensus on the policy to make it > > official > > > > >> (publish on website etc). I believe we have one. However, I did > not > &

Re: PR merge policy

t; > > > > > > >> Vlad, are you asking for a consensus on the policy to make it > official > > > >> (publish on website etc). I believe we have one. However, I did not > > see > > > >> much difference between what you said on Mar 26th to w

Re: PR merge policy

> > >> much difference between what you said on Mar 26th to what I proposed > on > > >> Mar > > >> 24th. Is the main difference any committer can merge (not just the > main > > >> reviewer) as long as there are no objections from others. In tha

Re: PR merge policy

reviewer) as long as there are no objections from others. In that case, I am fine with it. On Thu, Apr 27, 2017 at 7:44 AM, Vlad Rozov <v.ro...@datatorrent.com> wrote: This is a friendly reminder regarding PR merge policy. Thank you, Vlad On 3/23/17 12:58, Vlad Rozov wrote: Lately ther

Re: PR merge policy

reviewer) as long as there are no objections from others. In that case, I am fine with it. On Thu, Apr 27, 2017 at 7:44 AM, Vlad Rozov <v.ro...@datatorrent.com> wrote: > This is a friendly reminder regarding PR merge policy. > > Thank you, > > Vlad > > > On 3/23/17 12:58,

Re: PR merge policy

This is a friendly reminder regarding PR merge policy. Thank you, Vlad On 3/23/17 12:58, Vlad Rozov wrote: Lately there were few instances where PR open against apex-core and apex-malhar were merged just few hours after it being open and JIRA being raised without giving chance for other

Re: PR merge policy

I'd suggest to follow a slightly different protocol where timeout is more explicit. Any committer can say LGTM (using github approve changes?) and indicate intention to merge in a day or two (timeout may depend on complexity of changes and number of active PR reviewers). At that point any

Re: PR merge policy

Pramod, That is a good idea. A timeout will help PR be more efficient. Thks Amol E:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre* www.datatorrent.com *Join us at Apex Big Data World Mt View , April 4, 2017!* [image:

Re: PR merge policy

For the PR part with multiple reviewers, I suggest we pick a convention like the main reviewer has to wait till all the other reviewers say something like LGTM or a timeout period like 2 days before merging it. This will remove ambiguity, especially in cases where reviewers come in later after

PR merge policy

Lately there were few instances where PR open against apex-core and apex-malhar were merged just few hours after it being open and JIRA being raised without giving chance for other contributors to review and comment. I'd suggest that we stop such practice no matter how trivial those changes