You are viewing a plain text version of this content. The canonical link for it is here.

Posted to common-dev@hadoop.apache.org by "Elek, Marton" <el...@apache.org> on 2019/07/17 06:07:16 UTC

[VOTE] Force "squash and merge" option for PR merge on github UI

Hi,

Github UI (ui!) helps to merge Pull Requests to the proposed branch.
There are three different ways to do it [1]:

1. Keep all the different commits from the PR branch and create one
additional merge commit ("Create a merge commit")

2. Squash all the commits and commit the change as one patch ("Squash
and merge")

3. Keep all the different commits from the PR branch but rebase, merge
commit will be missing ("Rebase and merge")



As only the option 2 is compatible with the existing development
practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a lazy
consensus vote: If no objections withing 3 days, I will ask INFRA to
disable the options 1 and 3 to make the process less error prone.

Please let me know, what do you think,

Thanks a lot
Marton

ps: Personally I prefer to merge from local as it enables to sign the
commits and do a final build before push. But this is a different story,
this proposal is only about removing the options which are obviously
risky...

ps2: You can always do any kind of merge / commits from CLI, for example
to merge a feature branch together with keeping the history.

[1]:
https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github

---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Da Zhou <da...@gmail.com>.

sounds good!  +1

Regards,
Da

> On Jul 17, 2019, at 7:32 PM, Dinesh Chitlangia <dc...@cloudera.com.invalid> wrote:
> 
> +1, this is certainly useful.
> 
> Thank you,
> Dinesh
> 
> 
> 
> 
>> On Wed, Jul 17, 2019 at 10:04 PM Akira Ajisaka <aa...@apache.org> wrote:
>> 
>> Makes sense, +1
>> 
>>> On Thu, Jul 18, 2019 at 10:01 AM Sangjin Lee <sj...@apache.org> wrote:
>>> 
>>> +1. Sounds good to me.
>>> 
>>>> On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
>>>> 
>>>> +1
>>>> 
>>>> On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran
>> <stevel@cloudera.com.invalid
>>>>> 
>>>> wrote:
>>>> 
>>>>> +1 for squash and merge, with whoever does the merge adding the full
>>>> commit
>>>>> message for the logs, with JIRA, contributor(s) etc
>>>>> 
>>>>> One limit of the github process is that the author of the commit
>> becomes
>>>>> whoever hit the squash button, not whoever did the code, so it loses
>> the
>>>>> credit they are due. This is why I'm doing local merges (With some
>> help
>>>>> from smart-apply-patch). I think I'll have to explore
>> smart-apply-patch
>>>> to
>>>>> see if I can do even more with it
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org>
>> wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Github UI (ui!) helps to merge Pull Requests to the proposed
>> branch.
>>>>>> There are three different ways to do it [1]:
>>>>>> 
>>>>>> 1. Keep all the different commits from the PR branch and create one
>>>>>> additional merge commit ("Create a merge commit")
>>>>>> 
>>>>>> 2. Squash all the commits and commit the change as one patch
>> ("Squash
>>>>>> and merge")
>>>>>> 
>>>>>> 3. Keep all the different commits from the PR branch but rebase,
>> merge
>>>>>> commit will be missing ("Rebase and merge")
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> As only the option 2 is compatible with the existing development
>>>>>> practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a
>> lazy
>>>>>> consensus vote: If no objections withing 3 days, I will ask INFRA
>> to
>>>>>> disable the options 1 and 3 to make the process less error prone.
>>>>>> 
>>>>>> Please let me know, what do you think,
>>>>>> 
>>>>>> Thanks a lot
>>>>>> Marton
>>>>>> 
>>>>>> ps: Personally I prefer to merge from local as it enables to sign
>> the
>>>>>> commits and do a final build before push. But this is a different
>>>> story,
>>>>>> this proposal is only about removing the options which are
>> obviously
>>>>>> risky...
>>>>>> 
>>>>>> ps2: You can always do any kind of merge / commits from CLI, for
>>>> example
>>>>>> to merge a feature branch together with keeping the history.
>>>>>> 
>>>>>> [1]:
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
>>>>>> 
>>>>>> 
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>>>>>> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>> 
>>

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Da Zhou <da...@gmail.com>.

sounds good!  +1

Regards,
Da

> On Jul 17, 2019, at 7:32 PM, Dinesh Chitlangia <dc...@cloudera.com.invalid> wrote:
> 
> +1, this is certainly useful.
> 
> Thank you,
> Dinesh
> 
> 
> 
> 
>> On Wed, Jul 17, 2019 at 10:04 PM Akira Ajisaka <aa...@apache.org> wrote:
>> 
>> Makes sense, +1
>> 
>>> On Thu, Jul 18, 2019 at 10:01 AM Sangjin Lee <sj...@apache.org> wrote:
>>> 
>>> +1. Sounds good to me.
>>> 
>>>> On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
>>>> 
>>>> +1
>>>> 
>>>> On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran
>> <stevel@cloudera.com.invalid
>>>>> 
>>>> wrote:
>>>> 
>>>>> +1 for squash and merge, with whoever does the merge adding the full
>>>> commit
>>>>> message for the logs, with JIRA, contributor(s) etc
>>>>> 
>>>>> One limit of the github process is that the author of the commit
>> becomes
>>>>> whoever hit the squash button, not whoever did the code, so it loses
>> the
>>>>> credit they are due. This is why I'm doing local merges (With some
>> help
>>>>> from smart-apply-patch). I think I'll have to explore
>> smart-apply-patch
>>>> to
>>>>> see if I can do even more with it
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org>
>> wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Github UI (ui!) helps to merge Pull Requests to the proposed
>> branch.
>>>>>> There are three different ways to do it [1]:
>>>>>> 
>>>>>> 1. Keep all the different commits from the PR branch and create one
>>>>>> additional merge commit ("Create a merge commit")
>>>>>> 
>>>>>> 2. Squash all the commits and commit the change as one patch
>> ("Squash
>>>>>> and merge")
>>>>>> 
>>>>>> 3. Keep all the different commits from the PR branch but rebase,
>> merge
>>>>>> commit will be missing ("Rebase and merge")
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> As only the option 2 is compatible with the existing development
>>>>>> practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a
>> lazy
>>>>>> consensus vote: If no objections withing 3 days, I will ask INFRA
>> to
>>>>>> disable the options 1 and 3 to make the process less error prone.
>>>>>> 
>>>>>> Please let me know, what do you think,
>>>>>> 
>>>>>> Thanks a lot
>>>>>> Marton
>>>>>> 
>>>>>> ps: Personally I prefer to merge from local as it enables to sign
>> the
>>>>>> commits and do a final build before push. But this is a different
>>>> story,
>>>>>> this proposal is only about removing the options which are
>> obviously
>>>>>> risky...
>>>>>> 
>>>>>> ps2: You can always do any kind of merge / commits from CLI, for
>>>> example
>>>>>> to merge a feature branch together with keeping the history.
>>>>>> 
>>>>>> [1]:
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
>>>>>> 
>>>>>> 
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>>>>>> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>> 
>> 

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Da Zhou <da...@gmail.com>.

sounds good!  +1

Regards,
Da

> On Jul 17, 2019, at 7:32 PM, Dinesh Chitlangia <dc...@cloudera.com.invalid> wrote:
> 
> +1, this is certainly useful.
> 
> Thank you,
> Dinesh
> 
> 
> 
> 
>> On Wed, Jul 17, 2019 at 10:04 PM Akira Ajisaka <aa...@apache.org> wrote:
>> 
>> Makes sense, +1
>> 
>>> On Thu, Jul 18, 2019 at 10:01 AM Sangjin Lee <sj...@apache.org> wrote:
>>> 
>>> +1. Sounds good to me.
>>> 
>>>> On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
>>>> 
>>>> +1
>>>> 
>>>> On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran
>> <stevel@cloudera.com.invalid
>>>>> 
>>>> wrote:
>>>> 
>>>>> +1 for squash and merge, with whoever does the merge adding the full
>>>> commit
>>>>> message for the logs, with JIRA, contributor(s) etc
>>>>> 
>>>>> One limit of the github process is that the author of the commit
>> becomes
>>>>> whoever hit the squash button, not whoever did the code, so it loses
>> the
>>>>> credit they are due. This is why I'm doing local merges (With some
>> help
>>>>> from smart-apply-patch). I think I'll have to explore
>> smart-apply-patch
>>>> to
>>>>> see if I can do even more with it
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org>
>> wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Github UI (ui!) helps to merge Pull Requests to the proposed
>> branch.
>>>>>> There are three different ways to do it [1]:
>>>>>> 
>>>>>> 1. Keep all the different commits from the PR branch and create one
>>>>>> additional merge commit ("Create a merge commit")
>>>>>> 
>>>>>> 2. Squash all the commits and commit the change as one patch
>> ("Squash
>>>>>> and merge")
>>>>>> 
>>>>>> 3. Keep all the different commits from the PR branch but rebase,
>> merge
>>>>>> commit will be missing ("Rebase and merge")
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> As only the option 2 is compatible with the existing development
>>>>>> practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a
>> lazy
>>>>>> consensus vote: If no objections withing 3 days, I will ask INFRA
>> to
>>>>>> disable the options 1 and 3 to make the process less error prone.
>>>>>> 
>>>>>> Please let me know, what do you think,
>>>>>> 
>>>>>> Thanks a lot
>>>>>> Marton
>>>>>> 
>>>>>> ps: Personally I prefer to merge from local as it enables to sign
>> the
>>>>>> commits and do a final build before push. But this is a different
>>>> story,
>>>>>> this proposal is only about removing the options which are
>> obviously
>>>>>> risky...
>>>>>> 
>>>>>> ps2: You can always do any kind of merge / commits from CLI, for
>>>> example
>>>>>> to merge a feature branch together with keeping the history.
>>>>>> 
>>>>>> [1]:
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
>>>>>> 
>>>>>> 
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>>>>>> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>> 
>> 

---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Da Zhou <da...@gmail.com>.

sounds good!  +1

Regards,
Da

> On Jul 17, 2019, at 7:32 PM, Dinesh Chitlangia <dc...@cloudera.com.invalid> wrote:
> 
> +1, this is certainly useful.
> 
> Thank you,
> Dinesh
> 
> 
> 
> 
>> On Wed, Jul 17, 2019 at 10:04 PM Akira Ajisaka <aa...@apache.org> wrote:
>> 
>> Makes sense, +1
>> 
>>> On Thu, Jul 18, 2019 at 10:01 AM Sangjin Lee <sj...@apache.org> wrote:
>>> 
>>> +1. Sounds good to me.
>>> 
>>>> On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
>>>> 
>>>> +1
>>>> 
>>>> On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran
>> <stevel@cloudera.com.invalid
>>>>> 
>>>> wrote:
>>>> 
>>>>> +1 for squash and merge, with whoever does the merge adding the full
>>>> commit
>>>>> message for the logs, with JIRA, contributor(s) etc
>>>>> 
>>>>> One limit of the github process is that the author of the commit
>> becomes
>>>>> whoever hit the squash button, not whoever did the code, so it loses
>> the
>>>>> credit they are due. This is why I'm doing local merges (With some
>> help
>>>>> from smart-apply-patch). I think I'll have to explore
>> smart-apply-patch
>>>> to
>>>>> see if I can do even more with it
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org>
>> wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Github UI (ui!) helps to merge Pull Requests to the proposed
>> branch.
>>>>>> There are three different ways to do it [1]:
>>>>>> 
>>>>>> 1. Keep all the different commits from the PR branch and create one
>>>>>> additional merge commit ("Create a merge commit")
>>>>>> 
>>>>>> 2. Squash all the commits and commit the change as one patch
>> ("Squash
>>>>>> and merge")
>>>>>> 
>>>>>> 3. Keep all the different commits from the PR branch but rebase,
>> merge
>>>>>> commit will be missing ("Rebase and merge")
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> As only the option 2 is compatible with the existing development
>>>>>> practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a
>> lazy
>>>>>> consensus vote: If no objections withing 3 days, I will ask INFRA
>> to
>>>>>> disable the options 1 and 3 to make the process less error prone.
>>>>>> 
>>>>>> Please let me know, what do you think,
>>>>>> 
>>>>>> Thanks a lot
>>>>>> Marton
>>>>>> 
>>>>>> ps: Personally I prefer to merge from local as it enables to sign
>> the
>>>>>> commits and do a final build before push. But this is a different
>>>> story,
>>>>>> this proposal is only about removing the options which are
>> obviously
>>>>>> risky...
>>>>>> 
>>>>>> ps2: You can always do any kind of merge / commits from CLI, for
>>>> example
>>>>>> to merge a feature branch together with keeping the history.
>>>>>> 
>>>>>> [1]:
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
>>>>>> 
>>>>>> 
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>>>>>> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>> 
>> 

---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Da Zhou <da...@gmail.com>.

sounds good!  +1

Regards,
Da

> On Jul 17, 2019, at 7:32 PM, Dinesh Chitlangia <dc...@cloudera.com.invalid> wrote:
> 
> +1, this is certainly useful.
> 
> Thank you,
> Dinesh
> 
> 
> 
> 
>> On Wed, Jul 17, 2019 at 10:04 PM Akira Ajisaka <aa...@apache.org> wrote:
>> 
>> Makes sense, +1
>> 
>>> On Thu, Jul 18, 2019 at 10:01 AM Sangjin Lee <sj...@apache.org> wrote:
>>> 
>>> +1. Sounds good to me.
>>> 
>>>> On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
>>>> 
>>>> +1
>>>> 
>>>> On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran
>> <stevel@cloudera.com.invalid
>>>>> 
>>>> wrote:
>>>> 
>>>>> +1 for squash and merge, with whoever does the merge adding the full
>>>> commit
>>>>> message for the logs, with JIRA, contributor(s) etc
>>>>> 
>>>>> One limit of the github process is that the author of the commit
>> becomes
>>>>> whoever hit the squash button, not whoever did the code, so it loses
>> the
>>>>> credit they are due. This is why I'm doing local merges (With some
>> help
>>>>> from smart-apply-patch). I think I'll have to explore
>> smart-apply-patch
>>>> to
>>>>> see if I can do even more with it
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org>
>> wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Github UI (ui!) helps to merge Pull Requests to the proposed
>> branch.
>>>>>> There are three different ways to do it [1]:
>>>>>> 
>>>>>> 1. Keep all the different commits from the PR branch and create one
>>>>>> additional merge commit ("Create a merge commit")
>>>>>> 
>>>>>> 2. Squash all the commits and commit the change as one patch
>> ("Squash
>>>>>> and merge")
>>>>>> 
>>>>>> 3. Keep all the different commits from the PR branch but rebase,
>> merge
>>>>>> commit will be missing ("Rebase and merge")
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> As only the option 2 is compatible with the existing development
>>>>>> practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a
>> lazy
>>>>>> consensus vote: If no objections withing 3 days, I will ask INFRA
>> to
>>>>>> disable the options 1 and 3 to make the process less error prone.
>>>>>> 
>>>>>> Please let me know, what do you think,
>>>>>> 
>>>>>> Thanks a lot
>>>>>> Marton
>>>>>> 
>>>>>> ps: Personally I prefer to merge from local as it enables to sign
>> the
>>>>>> commits and do a final build before push. But this is a different
>>>> story,
>>>>>> this proposal is only about removing the options which are
>> obviously
>>>>>> risky...
>>>>>> 
>>>>>> ps2: You can always do any kind of merge / commits from CLI, for
>>>> example
>>>>>> to merge a feature branch together with keeping the history.
>>>>>> 
>>>>>> [1]:
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
>>>>>> 
>>>>>> 
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>>>>>> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>> 
>> 

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Dinesh Chitlangia <dc...@cloudera.com.INVALID>.

+1, this is certainly useful.

Thank you,
Dinesh




On Wed, Jul 17, 2019 at 10:04 PM Akira Ajisaka <aa...@apache.org> wrote:

> Makes sense, +1
>
> On Thu, Jul 18, 2019 at 10:01 AM Sangjin Lee <sj...@apache.org> wrote:
> >
> > +1. Sounds good to me.
> >
> > On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
> >
> > > +1
> > >
> > > On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran
> <stevel@cloudera.com.invalid
> > > >
> > > wrote:
> > >
> > > > +1 for squash and merge, with whoever does the merge adding the full
> > > commit
> > > > message for the logs, with JIRA, contributor(s) etc
> > > >
> > > > One limit of the github process is that the author of the commit
> becomes
> > > > whoever hit the squash button, not whoever did the code, so it loses
> the
> > > > credit they are due. This is why I'm doing local merges (With some
> help
> > > > from smart-apply-patch). I think I'll have to explore
> smart-apply-patch
> > > to
> > > > see if I can do even more with it
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org>
> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Github UI (ui!) helps to merge Pull Requests to the proposed
> branch.
> > > > > There are three different ways to do it [1]:
> > > > >
> > > > > 1. Keep all the different commits from the PR branch and create one
> > > > > additional merge commit ("Create a merge commit")
> > > > >
> > > > > 2. Squash all the commits and commit the change as one patch
> ("Squash
> > > > > and merge")
> > > > >
> > > > > 3. Keep all the different commits from the PR branch but rebase,
> merge
> > > > > commit will be missing ("Rebase and merge")
> > > > >
> > > > >
> > > > >
> > > > > As only the option 2 is compatible with the existing development
> > > > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a
> lazy
> > > > > consensus vote: If no objections withing 3 days, I will ask INFRA
> to
> > > > > disable the options 1 and 3 to make the process less error prone.
> > > > >
> > > > > Please let me know, what do you think,
> > > > >
> > > > > Thanks a lot
> > > > > Marton
> > > > >
> > > > > ps: Personally I prefer to merge from local as it enables to sign
> the
> > > > > commits and do a final build before push. But this is a different
> > > story,
> > > > > this proposal is only about removing the options which are
> obviously
> > > > > risky...
> > > > >
> > > > > ps2: You can always do any kind of merge / commits from CLI, for
> > > example
> > > > > to merge a feature branch together with keeping the history.
> > > > >
> > > > > [1]:
> > > > >
> > > > >
> > > >
> > >
> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > > > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> > > > >
> > > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Dinesh Chitlangia <dc...@cloudera.com.INVALID>.

+1, this is certainly useful.

Thank you,
Dinesh




On Wed, Jul 17, 2019 at 10:04 PM Akira Ajisaka <aa...@apache.org> wrote:

> Makes sense, +1
>
> On Thu, Jul 18, 2019 at 10:01 AM Sangjin Lee <sj...@apache.org> wrote:
> >
> > +1. Sounds good to me.
> >
> > On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
> >
> > > +1
> > >
> > > On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran
> <stevel@cloudera.com.invalid
> > > >
> > > wrote:
> > >
> > > > +1 for squash and merge, with whoever does the merge adding the full
> > > commit
> > > > message for the logs, with JIRA, contributor(s) etc
> > > >
> > > > One limit of the github process is that the author of the commit
> becomes
> > > > whoever hit the squash button, not whoever did the code, so it loses
> the
> > > > credit they are due. This is why I'm doing local merges (With some
> help
> > > > from smart-apply-patch). I think I'll have to explore
> smart-apply-patch
> > > to
> > > > see if I can do even more with it
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org>
> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Github UI (ui!) helps to merge Pull Requests to the proposed
> branch.
> > > > > There are three different ways to do it [1]:
> > > > >
> > > > > 1. Keep all the different commits from the PR branch and create one
> > > > > additional merge commit ("Create a merge commit")
> > > > >
> > > > > 2. Squash all the commits and commit the change as one patch
> ("Squash
> > > > > and merge")
> > > > >
> > > > > 3. Keep all the different commits from the PR branch but rebase,
> merge
> > > > > commit will be missing ("Rebase and merge")
> > > > >
> > > > >
> > > > >
> > > > > As only the option 2 is compatible with the existing development
> > > > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a
> lazy
> > > > > consensus vote: If no objections withing 3 days, I will ask INFRA
> to
> > > > > disable the options 1 and 3 to make the process less error prone.
> > > > >
> > > > > Please let me know, what do you think,
> > > > >
> > > > > Thanks a lot
> > > > > Marton
> > > > >
> > > > > ps: Personally I prefer to merge from local as it enables to sign
> the
> > > > > commits and do a final build before push. But this is a different
> > > story,
> > > > > this proposal is only about removing the options which are
> obviously
> > > > > risky...
> > > > >
> > > > > ps2: You can always do any kind of merge / commits from CLI, for
> > > example
> > > > > to merge a feature branch together with keeping the history.
> > > > >
> > > > > [1]:
> > > > >
> > > > >
> > > >
> > >
> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > > > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> > > > >
> > > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Dinesh Chitlangia <dc...@cloudera.com.INVALID>.

+1, this is certainly useful.

Thank you,
Dinesh




On Wed, Jul 17, 2019 at 10:04 PM Akira Ajisaka <aa...@apache.org> wrote:

> Makes sense, +1
>
> On Thu, Jul 18, 2019 at 10:01 AM Sangjin Lee <sj...@apache.org> wrote:
> >
> > +1. Sounds good to me.
> >
> > On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
> >
> > > +1
> > >
> > > On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran
> <stevel@cloudera.com.invalid
> > > >
> > > wrote:
> > >
> > > > +1 for squash and merge, with whoever does the merge adding the full
> > > commit
> > > > message for the logs, with JIRA, contributor(s) etc
> > > >
> > > > One limit of the github process is that the author of the commit
> becomes
> > > > whoever hit the squash button, not whoever did the code, so it loses
> the
> > > > credit they are due. This is why I'm doing local merges (With some
> help
> > > > from smart-apply-patch). I think I'll have to explore
> smart-apply-patch
> > > to
> > > > see if I can do even more with it
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org>
> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Github UI (ui!) helps to merge Pull Requests to the proposed
> branch.
> > > > > There are three different ways to do it [1]:
> > > > >
> > > > > 1. Keep all the different commits from the PR branch and create one
> > > > > additional merge commit ("Create a merge commit")
> > > > >
> > > > > 2. Squash all the commits and commit the change as one patch
> ("Squash
> > > > > and merge")
> > > > >
> > > > > 3. Keep all the different commits from the PR branch but rebase,
> merge
> > > > > commit will be missing ("Rebase and merge")
> > > > >
> > > > >
> > > > >
> > > > > As only the option 2 is compatible with the existing development
> > > > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a
> lazy
> > > > > consensus vote: If no objections withing 3 days, I will ask INFRA
> to
> > > > > disable the options 1 and 3 to make the process less error prone.
> > > > >
> > > > > Please let me know, what do you think,
> > > > >
> > > > > Thanks a lot
> > > > > Marton
> > > > >
> > > > > ps: Personally I prefer to merge from local as it enables to sign
> the
> > > > > commits and do a final build before push. But this is a different
> > > story,
> > > > > this proposal is only about removing the options which are
> obviously
> > > > > risky...
> > > > >
> > > > > ps2: You can always do any kind of merge / commits from CLI, for
> > > example
> > > > > to merge a feature branch together with keeping the history.
> > > > >
> > > > > [1]:
> > > > >
> > > > >
> > > >
> > >
> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > > > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> > > > >
> > > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Dinesh Chitlangia <dc...@cloudera.com.INVALID>.

+1, this is certainly useful.

Thank you,
Dinesh




On Wed, Jul 17, 2019 at 10:04 PM Akira Ajisaka <aa...@apache.org> wrote:

> Makes sense, +1
>
> On Thu, Jul 18, 2019 at 10:01 AM Sangjin Lee <sj...@apache.org> wrote:
> >
> > +1. Sounds good to me.
> >
> > On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
> >
> > > +1
> > >
> > > On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran
> <stevel@cloudera.com.invalid
> > > >
> > > wrote:
> > >
> > > > +1 for squash and merge, with whoever does the merge adding the full
> > > commit
> > > > message for the logs, with JIRA, contributor(s) etc
> > > >
> > > > One limit of the github process is that the author of the commit
> becomes
> > > > whoever hit the squash button, not whoever did the code, so it loses
> the
> > > > credit they are due. This is why I'm doing local merges (With some
> help
> > > > from smart-apply-patch). I think I'll have to explore
> smart-apply-patch
> > > to
> > > > see if I can do even more with it
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org>
> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Github UI (ui!) helps to merge Pull Requests to the proposed
> branch.
> > > > > There are three different ways to do it [1]:
> > > > >
> > > > > 1. Keep all the different commits from the PR branch and create one
> > > > > additional merge commit ("Create a merge commit")
> > > > >
> > > > > 2. Squash all the commits and commit the change as one patch
> ("Squash
> > > > > and merge")
> > > > >
> > > > > 3. Keep all the different commits from the PR branch but rebase,
> merge
> > > > > commit will be missing ("Rebase and merge")
> > > > >
> > > > >
> > > > >
> > > > > As only the option 2 is compatible with the existing development
> > > > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a
> lazy
> > > > > consensus vote: If no objections withing 3 days, I will ask INFRA
> to
> > > > > disable the options 1 and 3 to make the process less error prone.
> > > > >
> > > > > Please let me know, what do you think,
> > > > >
> > > > > Thanks a lot
> > > > > Marton
> > > > >
> > > > > ps: Personally I prefer to merge from local as it enables to sign
> the
> > > > > commits and do a final build before push. But this is a different
> > > story,
> > > > > this proposal is only about removing the options which are
> obviously
> > > > > risky...
> > > > >
> > > > > ps2: You can always do any kind of merge / commits from CLI, for
> > > example
> > > > > to merge a feature branch together with keeping the history.
> > > > >
> > > > > [1]:
> > > > >
> > > > >
> > > >
> > >
> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > > > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> > > > >
> > > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Akira Ajisaka <aa...@apache.org>.

Makes sense, +1

On Thu, Jul 18, 2019 at 10:01 AM Sangjin Lee <sj...@apache.org> wrote:
>
> +1. Sounds good to me.
>
> On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
>
> > +1
> >
> > On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran <stevel@cloudera.com.invalid
> > >
> > wrote:
> >
> > > +1 for squash and merge, with whoever does the merge adding the full
> > commit
> > > message for the logs, with JIRA, contributor(s) etc
> > >
> > > One limit of the github process is that the author of the commit becomes
> > > whoever hit the squash button, not whoever did the code, so it loses the
> > > credit they are due. This is why I'm doing local merges (With some help
> > > from smart-apply-patch). I think I'll have to explore smart-apply-patch
> > to
> > > see if I can do even more with it
> > >
> > >
> > >
> > >
> > > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org> wrote:
> > >
> > > > Hi,
> > > >
> > > > Github UI (ui!) helps to merge Pull Requests to the proposed branch.
> > > > There are three different ways to do it [1]:
> > > >
> > > > 1. Keep all the different commits from the PR branch and create one
> > > > additional merge commit ("Create a merge commit")
> > > >
> > > > 2. Squash all the commits and commit the change as one patch ("Squash
> > > > and merge")
> > > >
> > > > 3. Keep all the different commits from the PR branch but rebase, merge
> > > > commit will be missing ("Rebase and merge")
> > > >
> > > >
> > > >
> > > > As only the option 2 is compatible with the existing development
> > > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a lazy
> > > > consensus vote: If no objections withing 3 days, I will ask INFRA to
> > > > disable the options 1 and 3 to make the process less error prone.
> > > >
> > > > Please let me know, what do you think,
> > > >
> > > > Thanks a lot
> > > > Marton
> > > >
> > > > ps: Personally I prefer to merge from local as it enables to sign the
> > > > commits and do a final build before push. But this is a different
> > story,
> > > > this proposal is only about removing the options which are obviously
> > > > risky...
> > > >
> > > > ps2: You can always do any kind of merge / commits from CLI, for
> > example
> > > > to merge a feature branch together with keeping the history.
> > > >
> > > > [1]:
> > > >
> > > >
> > >
> > https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> > > >
> > > >
> > >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Akira Ajisaka <aa...@apache.org>.

Makes sense, +1

On Thu, Jul 18, 2019 at 10:01 AM Sangjin Lee <sj...@apache.org> wrote:
>
> +1. Sounds good to me.
>
> On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
>
> > +1
> >
> > On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran <stevel@cloudera.com.invalid
> > >
> > wrote:
> >
> > > +1 for squash and merge, with whoever does the merge adding the full
> > commit
> > > message for the logs, with JIRA, contributor(s) etc
> > >
> > > One limit of the github process is that the author of the commit becomes
> > > whoever hit the squash button, not whoever did the code, so it loses the
> > > credit they are due. This is why I'm doing local merges (With some help
> > > from smart-apply-patch). I think I'll have to explore smart-apply-patch
> > to
> > > see if I can do even more with it
> > >
> > >
> > >
> > >
> > > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org> wrote:
> > >
> > > > Hi,
> > > >
> > > > Github UI (ui!) helps to merge Pull Requests to the proposed branch.
> > > > There are three different ways to do it [1]:
> > > >
> > > > 1. Keep all the different commits from the PR branch and create one
> > > > additional merge commit ("Create a merge commit")
> > > >
> > > > 2. Squash all the commits and commit the change as one patch ("Squash
> > > > and merge")
> > > >
> > > > 3. Keep all the different commits from the PR branch but rebase, merge
> > > > commit will be missing ("Rebase and merge")
> > > >
> > > >
> > > >
> > > > As only the option 2 is compatible with the existing development
> > > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a lazy
> > > > consensus vote: If no objections withing 3 days, I will ask INFRA to
> > > > disable the options 1 and 3 to make the process less error prone.
> > > >
> > > > Please let me know, what do you think,
> > > >
> > > > Thanks a lot
> > > > Marton
> > > >
> > > > ps: Personally I prefer to merge from local as it enables to sign the
> > > > commits and do a final build before push. But this is a different
> > story,
> > > > this proposal is only about removing the options which are obviously
> > > > risky...
> > > >
> > > > ps2: You can always do any kind of merge / commits from CLI, for
> > example
> > > > to merge a feature branch together with keeping the history.
> > > >
> > > > [1]:
> > > >
> > > >
> > >
> > https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> > > >
> > > >
> > >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Akira Ajisaka <aa...@apache.org>.

Makes sense, +1

On Thu, Jul 18, 2019 at 10:01 AM Sangjin Lee <sj...@apache.org> wrote:
>
> +1. Sounds good to me.
>
> On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
>
> > +1
> >
> > On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran <stevel@cloudera.com.invalid
> > >
> > wrote:
> >
> > > +1 for squash and merge, with whoever does the merge adding the full
> > commit
> > > message for the logs, with JIRA, contributor(s) etc
> > >
> > > One limit of the github process is that the author of the commit becomes
> > > whoever hit the squash button, not whoever did the code, so it loses the
> > > credit they are due. This is why I'm doing local merges (With some help
> > > from smart-apply-patch). I think I'll have to explore smart-apply-patch
> > to
> > > see if I can do even more with it
> > >
> > >
> > >
> > >
> > > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org> wrote:
> > >
> > > > Hi,
> > > >
> > > > Github UI (ui!) helps to merge Pull Requests to the proposed branch.
> > > > There are three different ways to do it [1]:
> > > >
> > > > 1. Keep all the different commits from the PR branch and create one
> > > > additional merge commit ("Create a merge commit")
> > > >
> > > > 2. Squash all the commits and commit the change as one patch ("Squash
> > > > and merge")
> > > >
> > > > 3. Keep all the different commits from the PR branch but rebase, merge
> > > > commit will be missing ("Rebase and merge")
> > > >
> > > >
> > > >
> > > > As only the option 2 is compatible with the existing development
> > > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a lazy
> > > > consensus vote: If no objections withing 3 days, I will ask INFRA to
> > > > disable the options 1 and 3 to make the process less error prone.
> > > >
> > > > Please let me know, what do you think,
> > > >
> > > > Thanks a lot
> > > > Marton
> > > >
> > > > ps: Personally I prefer to merge from local as it enables to sign the
> > > > commits and do a final build before push. But this is a different
> > story,
> > > > this proposal is only about removing the options which are obviously
> > > > risky...
> > > >
> > > > ps2: You can always do any kind of merge / commits from CLI, for
> > example
> > > > to merge a feature branch together with keeping the history.
> > > >
> > > > [1]:
> > > >
> > > >
> > >
> > https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> > > >
> > > >
> > >
> >

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Akira Ajisaka <aa...@apache.org>.

Makes sense, +1

On Thu, Jul 18, 2019 at 10:01 AM Sangjin Lee <sj...@apache.org> wrote:
>
> +1. Sounds good to me.
>
> On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
>
> > +1
> >
> > On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran <stevel@cloudera.com.invalid
> > >
> > wrote:
> >
> > > +1 for squash and merge, with whoever does the merge adding the full
> > commit
> > > message for the logs, with JIRA, contributor(s) etc
> > >
> > > One limit of the github process is that the author of the commit becomes
> > > whoever hit the squash button, not whoever did the code, so it loses the
> > > credit they are due. This is why I'm doing local merges (With some help
> > > from smart-apply-patch). I think I'll have to explore smart-apply-patch
> > to
> > > see if I can do even more with it
> > >
> > >
> > >
> > >
> > > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org> wrote:
> > >
> > > > Hi,
> > > >
> > > > Github UI (ui!) helps to merge Pull Requests to the proposed branch.
> > > > There are three different ways to do it [1]:
> > > >
> > > > 1. Keep all the different commits from the PR branch and create one
> > > > additional merge commit ("Create a merge commit")
> > > >
> > > > 2. Squash all the commits and commit the change as one patch ("Squash
> > > > and merge")
> > > >
> > > > 3. Keep all the different commits from the PR branch but rebase, merge
> > > > commit will be missing ("Rebase and merge")
> > > >
> > > >
> > > >
> > > > As only the option 2 is compatible with the existing development
> > > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a lazy
> > > > consensus vote: If no objections withing 3 days, I will ask INFRA to
> > > > disable the options 1 and 3 to make the process less error prone.
> > > >
> > > > Please let me know, what do you think,
> > > >
> > > > Thanks a lot
> > > > Marton
> > > >
> > > > ps: Personally I prefer to merge from local as it enables to sign the
> > > > commits and do a final build before push. But this is a different
> > story,
> > > > this proposal is only about removing the options which are obviously
> > > > risky...
> > > >
> > > > ps2: You can always do any kind of merge / commits from CLI, for
> > example
> > > > to merge a feature branch together with keeping the history.
> > > >
> > > > [1]:
> > > >
> > > >
> > >
> > https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> > > >
> > > >
> > >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Akira Ajisaka <aa...@apache.org>.

Makes sense, +1

On Thu, Jul 18, 2019 at 10:01 AM Sangjin Lee <sj...@apache.org> wrote:
>
> +1. Sounds good to me.
>
> On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
>
> > +1
> >
> > On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran <stevel@cloudera.com.invalid
> > >
> > wrote:
> >
> > > +1 for squash and merge, with whoever does the merge adding the full
> > commit
> > > message for the logs, with JIRA, contributor(s) etc
> > >
> > > One limit of the github process is that the author of the commit becomes
> > > whoever hit the squash button, not whoever did the code, so it loses the
> > > credit they are due. This is why I'm doing local merges (With some help
> > > from smart-apply-patch). I think I'll have to explore smart-apply-patch
> > to
> > > see if I can do even more with it
> > >
> > >
> > >
> > >
> > > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org> wrote:
> > >
> > > > Hi,
> > > >
> > > > Github UI (ui!) helps to merge Pull Requests to the proposed branch.
> > > > There are three different ways to do it [1]:
> > > >
> > > > 1. Keep all the different commits from the PR branch and create one
> > > > additional merge commit ("Create a merge commit")
> > > >
> > > > 2. Squash all the commits and commit the change as one patch ("Squash
> > > > and merge")
> > > >
> > > > 3. Keep all the different commits from the PR branch but rebase, merge
> > > > commit will be missing ("Rebase and merge")
> > > >
> > > >
> > > >
> > > > As only the option 2 is compatible with the existing development
> > > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a lazy
> > > > consensus vote: If no objections withing 3 days, I will ask INFRA to
> > > > disable the options 1 and 3 to make the process less error prone.
> > > >
> > > > Please let me know, what do you think,
> > > >
> > > > Thanks a lot
> > > > Marton
> > > >
> > > > ps: Personally I prefer to merge from local as it enables to sign the
> > > > commits and do a final build before push. But this is a different
> > story,
> > > > this proposal is only about removing the options which are obviously
> > > > risky...
> > > >
> > > > ps2: You can always do any kind of merge / commits from CLI, for
> > example
> > > > to merge a feature branch together with keeping the history.
> > > >
> > > > [1]:
> > > >
> > > >
> > >
> > https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> > > >
> > > >
> > >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Sangjin Lee <sj...@apache.org>.

+1. Sounds good to me.

On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:

> +1
>
> On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran <stevel@cloudera.com.invalid
> >
> wrote:
>
> > +1 for squash and merge, with whoever does the merge adding the full
> commit
> > message for the logs, with JIRA, contributor(s) etc
> >
> > One limit of the github process is that the author of the commit becomes
> > whoever hit the squash button, not whoever did the code, so it loses the
> > credit they are due. This is why I'm doing local merges (With some help
> > from smart-apply-patch). I think I'll have to explore smart-apply-patch
> to
> > see if I can do even more with it
> >
> >
> >
> >
> > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org> wrote:
> >
> > > Hi,
> > >
> > > Github UI (ui!) helps to merge Pull Requests to the proposed branch.
> > > There are three different ways to do it [1]:
> > >
> > > 1. Keep all the different commits from the PR branch and create one
> > > additional merge commit ("Create a merge commit")
> > >
> > > 2. Squash all the commits and commit the change as one patch ("Squash
> > > and merge")
> > >
> > > 3. Keep all the different commits from the PR branch but rebase, merge
> > > commit will be missing ("Rebase and merge")
> > >
> > >
> > >
> > > As only the option 2 is compatible with the existing development
> > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a lazy
> > > consensus vote: If no objections withing 3 days, I will ask INFRA to
> > > disable the options 1 and 3 to make the process less error prone.
> > >
> > > Please let me know, what do you think,
> > >
> > > Thanks a lot
> > > Marton
> > >
> > > ps: Personally I prefer to merge from local as it enables to sign the
> > > commits and do a final build before push. But this is a different
> story,
> > > this proposal is only about removing the options which are obviously
> > > risky...
> > >
> > > ps2: You can always do any kind of merge / commits from CLI, for
> example
> > > to merge a feature branch together with keeping the history.
> > >
> > > [1]:
> > >
> > >
> >
> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> > >
> > >
> >
>

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Sunil Govindan <su...@apache.org>.

Hi All

INFRA-18777 is closed and github UI has disabled #1 and #3. Only Squash and
Merge is possible.
Could we start using this option (merge from UI) from now onwards ?

- Sunil

On Mon, Jul 22, 2019 at 10:24 AM Bharat Viswanadham
<bv...@cloudera.com.invalid> wrote:

> +1 for squash and merge.
>
> And if we use Github UI, the original author will be shown as the original
> author of the code, not who clicks the squash and merge.
>
> [image: Screen Shot 2019-07-17 at 11.58.51 AM.png]
>
> Like in the screenshot arp7 committed the change from GithubUI, but the
> author is still been shown as the original author "bharatviswa504".
>
> * ef66e4999f3 N - HDDS-1666. Issue in openKey when allocating block.
> (#943) (2 days ago) <Bharat Viswanadham> <Arpit Agarwal>
> Thanks,
> Bharat
>
>
>
> On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
>
>> +1
>>
>> On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran
>> <st...@cloudera.com.invalid>
>> wrote:
>>
>> > +1 for squash and merge, with whoever does the merge adding the full
>> commit
>> > message for the logs, with JIRA, contributor(s) etc
>> >
>> > One limit of the github process is that the author of the commit becomes
>> > whoever hit the squash button, not whoever did the code, so it loses the
>> > credit they are due. This is why I'm doing local merges (With some help
>> > from smart-apply-patch). I think I'll have to explore smart-apply-patch
>> to
>> > see if I can do even more with it
>> >
>> >
>> >
>> >
>> > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org> wrote:
>> >
>> > > Hi,
>> > >
>> > > Github UI (ui!) helps to merge Pull Requests to the proposed branch.
>> > > There are three different ways to do it [1]:
>> > >
>> > > 1. Keep all the different commits from the PR branch and create one
>> > > additional merge commit ("Create a merge commit")
>> > >
>> > > 2. Squash all the commits and commit the change as one patch ("Squash
>> > > and merge")
>> > >
>> > > 3. Keep all the different commits from the PR branch but rebase, merge
>> > > commit will be missing ("Rebase and merge")
>> > >
>> > >
>> > >
>> > > As only the option 2 is compatible with the existing development
>> > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a lazy
>> > > consensus vote: If no objections withing 3 days, I will ask INFRA to
>> > > disable the options 1 and 3 to make the process less error prone.
>> > >
>> > > Please let me know, what do you think,
>> > >
>> > > Thanks a lot
>> > > Marton
>> > >
>> > > ps: Personally I prefer to merge from local as it enables to sign the
>> > > commits and do a final build before push. But this is a different
>> story,
>> > > this proposal is only about removing the options which are obviously
>> > > risky...
>> > >
>> > > ps2: You can always do any kind of merge / commits from CLI, for
>> example
>> > > to merge a feature branch together with keeping the history.
>> > >
>> > > [1]:
>> > >
>> > >
>> >
>> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>> > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>> > >
>> > >
>> >
>>
>

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Sunil Govindan <su...@apache.org>.

Hi All

INFRA-18777 is closed and github UI has disabled #1 and #3. Only Squash and
Merge is possible.
Could we start using this option (merge from UI) from now onwards ?

- Sunil

On Mon, Jul 22, 2019 at 10:24 AM Bharat Viswanadham
<bv...@cloudera.com.invalid> wrote:

> +1 for squash and merge.
>
> And if we use Github UI, the original author will be shown as the original
> author of the code, not who clicks the squash and merge.
>
> [image: Screen Shot 2019-07-17 at 11.58.51 AM.png]
>
> Like in the screenshot arp7 committed the change from GithubUI, but the
> author is still been shown as the original author "bharatviswa504".
>
> * ef66e4999f3 N - HDDS-1666. Issue in openKey when allocating block.
> (#943) (2 days ago) <Bharat Viswanadham> <Arpit Agarwal>
> Thanks,
> Bharat
>
>
>
> On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
>
>> +1
>>
>> On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran
>> <st...@cloudera.com.invalid>
>> wrote:
>>
>> > +1 for squash and merge, with whoever does the merge adding the full
>> commit
>> > message for the logs, with JIRA, contributor(s) etc
>> >
>> > One limit of the github process is that the author of the commit becomes
>> > whoever hit the squash button, not whoever did the code, so it loses the
>> > credit they are due. This is why I'm doing local merges (With some help
>> > from smart-apply-patch). I think I'll have to explore smart-apply-patch
>> to
>> > see if I can do even more with it
>> >
>> >
>> >
>> >
>> > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org> wrote:
>> >
>> > > Hi,
>> > >
>> > > Github UI (ui!) helps to merge Pull Requests to the proposed branch.
>> > > There are three different ways to do it [1]:
>> > >
>> > > 1. Keep all the different commits from the PR branch and create one
>> > > additional merge commit ("Create a merge commit")
>> > >
>> > > 2. Squash all the commits and commit the change as one patch ("Squash
>> > > and merge")
>> > >
>> > > 3. Keep all the different commits from the PR branch but rebase, merge
>> > > commit will be missing ("Rebase and merge")
>> > >
>> > >
>> > >
>> > > As only the option 2 is compatible with the existing development
>> > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a lazy
>> > > consensus vote: If no objections withing 3 days, I will ask INFRA to
>> > > disable the options 1 and 3 to make the process less error prone.
>> > >
>> > > Please let me know, what do you think,
>> > >
>> > > Thanks a lot
>> > > Marton
>> > >
>> > > ps: Personally I prefer to merge from local as it enables to sign the
>> > > commits and do a final build before push. But this is a different
>> story,
>> > > this proposal is only about removing the options which are obviously
>> > > risky...
>> > >
>> > > ps2: You can always do any kind of merge / commits from CLI, for
>> example
>> > > to merge a feature branch together with keeping the history.
>> > >
>> > > [1]:
>> > >
>> > >
>> >
>> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>> > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>> > >
>> > >
>> >
>>
>

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Sunil Govindan <su...@apache.org>.

Hi All

INFRA-18777 is closed and github UI has disabled #1 and #3. Only Squash and
Merge is possible.
Could we start using this option (merge from UI) from now onwards ?

- Sunil

On Mon, Jul 22, 2019 at 10:24 AM Bharat Viswanadham
<bv...@cloudera.com.invalid> wrote:

> +1 for squash and merge.
>
> And if we use Github UI, the original author will be shown as the original
> author of the code, not who clicks the squash and merge.
>
> [image: Screen Shot 2019-07-17 at 11.58.51 AM.png]
>
> Like in the screenshot arp7 committed the change from GithubUI, but the
> author is still been shown as the original author "bharatviswa504".
>
> * ef66e4999f3 N - HDDS-1666. Issue in openKey when allocating block.
> (#943) (2 days ago) <Bharat Viswanadham> <Arpit Agarwal>
> Thanks,
> Bharat
>
>
>
> On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
>
>> +1
>>
>> On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran
>> <st...@cloudera.com.invalid>
>> wrote:
>>
>> > +1 for squash and merge, with whoever does the merge adding the full
>> commit
>> > message for the logs, with JIRA, contributor(s) etc
>> >
>> > One limit of the github process is that the author of the commit becomes
>> > whoever hit the squash button, not whoever did the code, so it loses the
>> > credit they are due. This is why I'm doing local merges (With some help
>> > from smart-apply-patch). I think I'll have to explore smart-apply-patch
>> to
>> > see if I can do even more with it
>> >
>> >
>> >
>> >
>> > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org> wrote:
>> >
>> > > Hi,
>> > >
>> > > Github UI (ui!) helps to merge Pull Requests to the proposed branch.
>> > > There are three different ways to do it [1]:
>> > >
>> > > 1. Keep all the different commits from the PR branch and create one
>> > > additional merge commit ("Create a merge commit")
>> > >
>> > > 2. Squash all the commits and commit the change as one patch ("Squash
>> > > and merge")
>> > >
>> > > 3. Keep all the different commits from the PR branch but rebase, merge
>> > > commit will be missing ("Rebase and merge")
>> > >
>> > >
>> > >
>> > > As only the option 2 is compatible with the existing development
>> > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a lazy
>> > > consensus vote: If no objections withing 3 days, I will ask INFRA to
>> > > disable the options 1 and 3 to make the process less error prone.
>> > >
>> > > Please let me know, what do you think,
>> > >
>> > > Thanks a lot
>> > > Marton
>> > >
>> > > ps: Personally I prefer to merge from local as it enables to sign the
>> > > commits and do a final build before push. But this is a different
>> story,
>> > > this proposal is only about removing the options which are obviously
>> > > risky...
>> > >
>> > > ps2: You can always do any kind of merge / commits from CLI, for
>> example
>> > > to merge a feature branch together with keeping the history.
>> > >
>> > > [1]:
>> > >
>> > >
>> >
>> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>> > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>> > >
>> > >
>> >
>>
>

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Sunil Govindan <su...@apache.org>.

Hi All

INFRA-18777 is closed and github UI has disabled #1 and #3. Only Squash and
Merge is possible.
Could we start using this option (merge from UI) from now onwards ?

- Sunil

On Mon, Jul 22, 2019 at 10:24 AM Bharat Viswanadham
<bv...@cloudera.com.invalid> wrote:

> +1 for squash and merge.
>
> And if we use Github UI, the original author will be shown as the original
> author of the code, not who clicks the squash and merge.
>
> [image: Screen Shot 2019-07-17 at 11.58.51 AM.png]
>
> Like in the screenshot arp7 committed the change from GithubUI, but the
> author is still been shown as the original author "bharatviswa504".
>
> * ef66e4999f3 N - HDDS-1666. Issue in openKey when allocating block.
> (#943) (2 days ago) <Bharat Viswanadham> <Arpit Agarwal>
> Thanks,
> Bharat
>
>
>
> On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
>
>> +1
>>
>> On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran
>> <st...@cloudera.com.invalid>
>> wrote:
>>
>> > +1 for squash and merge, with whoever does the merge adding the full
>> commit
>> > message for the logs, with JIRA, contributor(s) etc
>> >
>> > One limit of the github process is that the author of the commit becomes
>> > whoever hit the squash button, not whoever did the code, so it loses the
>> > credit they are due. This is why I'm doing local merges (With some help
>> > from smart-apply-patch). I think I'll have to explore smart-apply-patch
>> to
>> > see if I can do even more with it
>> >
>> >
>> >
>> >
>> > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org> wrote:
>> >
>> > > Hi,
>> > >
>> > > Github UI (ui!) helps to merge Pull Requests to the proposed branch.
>> > > There are three different ways to do it [1]:
>> > >
>> > > 1. Keep all the different commits from the PR branch and create one
>> > > additional merge commit ("Create a merge commit")
>> > >
>> > > 2. Squash all the commits and commit the change as one patch ("Squash
>> > > and merge")
>> > >
>> > > 3. Keep all the different commits from the PR branch but rebase, merge
>> > > commit will be missing ("Rebase and merge")
>> > >
>> > >
>> > >
>> > > As only the option 2 is compatible with the existing development
>> > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a lazy
>> > > consensus vote: If no objections withing 3 days, I will ask INFRA to
>> > > disable the options 1 and 3 to make the process less error prone.
>> > >
>> > > Please let me know, what do you think,
>> > >
>> > > Thanks a lot
>> > > Marton
>> > >
>> > > ps: Personally I prefer to merge from local as it enables to sign the
>> > > commits and do a final build before push. But this is a different
>> story,
>> > > this proposal is only about removing the options which are obviously
>> > > risky...
>> > >
>> > > ps2: You can always do any kind of merge / commits from CLI, for
>> example
>> > > to merge a feature branch together with keeping the history.
>> > >
>> > > [1]:
>> > >
>> > >
>> >
>> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>> > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>> > >
>> > >
>> >
>>
>

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Sunil Govindan <su...@apache.org>.

Hi All

INFRA-18777 is closed and github UI has disabled #1 and #3. Only Squash and
Merge is possible.
Could we start using this option (merge from UI) from now onwards ?

- Sunil

On Mon, Jul 22, 2019 at 10:24 AM Bharat Viswanadham
<bv...@cloudera.com.invalid> wrote:

> +1 for squash and merge.
>
> And if we use Github UI, the original author will be shown as the original
> author of the code, not who clicks the squash and merge.
>
> [image: Screen Shot 2019-07-17 at 11.58.51 AM.png]
>
> Like in the screenshot arp7 committed the change from GithubUI, but the
> author is still been shown as the original author "bharatviswa504".
>
> * ef66e4999f3 N - HDDS-1666. Issue in openKey when allocating block.
> (#943) (2 days ago) <Bharat Viswanadham> <Arpit Agarwal>
> Thanks,
> Bharat
>
>
>
> On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:
>
>> +1
>>
>> On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran
>> <st...@cloudera.com.invalid>
>> wrote:
>>
>> > +1 for squash and merge, with whoever does the merge adding the full
>> commit
>> > message for the logs, with JIRA, contributor(s) etc
>> >
>> > One limit of the github process is that the author of the commit becomes
>> > whoever hit the squash button, not whoever did the code, so it loses the
>> > credit they are due. This is why I'm doing local merges (With some help
>> > from smart-apply-patch). I think I'll have to explore smart-apply-patch
>> to
>> > see if I can do even more with it
>> >
>> >
>> >
>> >
>> > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org> wrote:
>> >
>> > > Hi,
>> > >
>> > > Github UI (ui!) helps to merge Pull Requests to the proposed branch.
>> > > There are three different ways to do it [1]:
>> > >
>> > > 1. Keep all the different commits from the PR branch and create one
>> > > additional merge commit ("Create a merge commit")
>> > >
>> > > 2. Squash all the commits and commit the change as one patch ("Squash
>> > > and merge")
>> > >
>> > > 3. Keep all the different commits from the PR branch but rebase, merge
>> > > commit will be missing ("Rebase and merge")
>> > >
>> > >
>> > >
>> > > As only the option 2 is compatible with the existing development
>> > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a lazy
>> > > consensus vote: If no objections withing 3 days, I will ask INFRA to
>> > > disable the options 1 and 3 to make the process less error prone.
>> > >
>> > > Please let me know, what do you think,
>> > >
>> > > Thanks a lot
>> > > Marton
>> > >
>> > > ps: Personally I prefer to merge from local as it enables to sign the
>> > > commits and do a final build before push. But this is a different
>> story,
>> > > this proposal is only about removing the options which are obviously
>> > > risky...
>> > >
>> > > ps2: You can always do any kind of merge / commits from CLI, for
>> example
>> > > to merge a feature branch together with keeping the history.
>> > >
>> > > [1]:
>> > >
>> > >
>> >
>> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>> > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>> > >
>> > >
>> >
>>
>

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Bharat Viswanadham <bv...@cloudera.com.INVALID>.

+1 for squash and merge.

And if we use Github UI, the original author will be shown as the original
author of the code, not who clicks the squash and merge.

[image: Screen Shot 2019-07-17 at 11.58.51 AM.png]

Like in the screenshot arp7 committed the change from GithubUI, but the
author is still been shown as the original author "bharatviswa504".

* ef66e4999f3 N - HDDS-1666. Issue in openKey when allocating block. (#943) (2
days ago) <Bharat Viswanadham> <Arpit Agarwal>
Thanks,
Bharat



On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:

> +1
>
> On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran <stevel@cloudera.com.invalid
> >
> wrote:
>
> > +1 for squash and merge, with whoever does the merge adding the full
> commit
> > message for the logs, with JIRA, contributor(s) etc
> >
> > One limit of the github process is that the author of the commit becomes
> > whoever hit the squash button, not whoever did the code, so it loses the
> > credit they are due. This is why I'm doing local merges (With some help
> > from smart-apply-patch). I think I'll have to explore smart-apply-patch
> to
> > see if I can do even more with it
> >
> >
> >
> >
> > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org> wrote:
> >
> > > Hi,
> > >
> > > Github UI (ui!) helps to merge Pull Requests to the proposed branch.
> > > There are three different ways to do it [1]:
> > >
> > > 1. Keep all the different commits from the PR branch and create one
> > > additional merge commit ("Create a merge commit")
> > >
> > > 2. Squash all the commits and commit the change as one patch ("Squash
> > > and merge")
> > >
> > > 3. Keep all the different commits from the PR branch but rebase, merge
> > > commit will be missing ("Rebase and merge")
> > >
> > >
> > >
> > > As only the option 2 is compatible with the existing development
> > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a lazy
> > > consensus vote: If no objections withing 3 days, I will ask INFRA to
> > > disable the options 1 and 3 to make the process less error prone.
> > >
> > > Please let me know, what do you think,
> > >
> > > Thanks a lot
> > > Marton
> > >
> > > ps: Personally I prefer to merge from local as it enables to sign the
> > > commits and do a final build before push. But this is a different
> story,
> > > this proposal is only about removing the options which are obviously
> > > risky...
> > >
> > > ps2: You can always do any kind of merge / commits from CLI, for
> example
> > > to merge a feature branch together with keeping the history.
> > >
> > > [1]:
> > >
> > >
> >
> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> > >
> > >
> >
>

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Sangjin Lee <sj...@apache.org>.

+1. Sounds good to me.

On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:

> +1
>
> On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran <stevel@cloudera.com.invalid
> >
> wrote:
>
> > +1 for squash and merge, with whoever does the merge adding the full
> commit
> > message for the logs, with JIRA, contributor(s) etc
> >
> > One limit of the github process is that the author of the commit becomes
> > whoever hit the squash button, not whoever did the code, so it loses the
> > credit they are due. This is why I'm doing local merges (With some help
> > from smart-apply-patch). I think I'll have to explore smart-apply-patch
> to
> > see if I can do even more with it
> >
> >
> >
> >
> > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org> wrote:
> >
> > > Hi,
> > >
> > > Github UI (ui!) helps to merge Pull Requests to the proposed branch.
> > > There are three different ways to do it [1]:
> > >
> > > 1. Keep all the different commits from the PR branch and create one
> > > additional merge commit ("Create a merge commit")
> > >
> > > 2. Squash all the commits and commit the change as one patch ("Squash
> > > and merge")
> > >
> > > 3. Keep all the different commits from the PR branch but rebase, merge
> > > commit will be missing ("Rebase and merge")
> > >
> > >
> > >
> > > As only the option 2 is compatible with the existing development
> > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a lazy
> > > consensus vote: If no objections withing 3 days, I will ask INFRA to
> > > disable the options 1 and 3 to make the process less error prone.
> > >
> > > Please let me know, what do you think,
> > >
> > > Thanks a lot
> > > Marton
> > >
> > > ps: Personally I prefer to merge from local as it enables to sign the
> > > commits and do a final build before push. But this is a different
> story,
> > > this proposal is only about removing the options which are obviously
> > > risky...
> > >
> > > ps2: You can always do any kind of merge / commits from CLI, for
> example
> > > to merge a feature branch together with keeping the history.
> > >
> > > [1]:
> > >
> > >
> >
> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> > >
> > >
> >
>

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Sangjin Lee <sj...@apache.org>.

+1. Sounds good to me.

On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:

> +1
>
> On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran <stevel@cloudera.com.invalid
> >
> wrote:
>
> > +1 for squash and merge, with whoever does the merge adding the full
> commit
> > message for the logs, with JIRA, contributor(s) etc
> >
> > One limit of the github process is that the author of the commit becomes
> > whoever hit the squash button, not whoever did the code, so it loses the
> > credit they are due. This is why I'm doing local merges (With some help
> > from smart-apply-patch). I think I'll have to explore smart-apply-patch
> to
> > see if I can do even more with it
> >
> >
> >
> >
> > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org> wrote:
> >
> > > Hi,
> > >
> > > Github UI (ui!) helps to merge Pull Requests to the proposed branch.
> > > There are three different ways to do it [1]:
> > >
> > > 1. Keep all the different commits from the PR branch and create one
> > > additional merge commit ("Create a merge commit")
> > >
> > > 2. Squash all the commits and commit the change as one patch ("Squash
> > > and merge")
> > >
> > > 3. Keep all the different commits from the PR branch but rebase, merge
> > > commit will be missing ("Rebase and merge")
> > >
> > >
> > >
> > > As only the option 2 is compatible with the existing development
> > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a lazy
> > > consensus vote: If no objections withing 3 days, I will ask INFRA to
> > > disable the options 1 and 3 to make the process less error prone.
> > >
> > > Please let me know, what do you think,
> > >
> > > Thanks a lot
> > > Marton
> > >
> > > ps: Personally I prefer to merge from local as it enables to sign the
> > > commits and do a final build before push. But this is a different
> story,
> > > this proposal is only about removing the options which are obviously
> > > risky...
> > >
> > > ps2: You can always do any kind of merge / commits from CLI, for
> example
> > > to merge a feature branch together with keeping the history.
> > >
> > > [1]:
> > >
> > >
> >
> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> > >
> > >
> >
>

Re: [VOTE] Force "squash and merge" option for PR merge on github UI

Posted by Sangjin Lee <sj...@apache.org>.

+1. Sounds good to me.

On Wed, Jul 17, 2019 at 10:20 AM Iñigo Goiri <el...@gmail.com> wrote:

> +1
>
> On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran <stevel@cloudera.com.invalid
> >
> wrote:
>
> > +1 for squash and merge, with whoever does the merge adding the full
> commit
> > message for the logs, with JIRA, contributor(s) etc
> >
> > One limit of the github process is that the author of the commit becomes
> > whoever hit the squash button, not whoever did the code, so it loses the
> > credit they are due. This is why I'm doing local merges (With some help
> > from smart-apply-patch). I think I'll have to explore smart-apply-patch
> to
> > see if I can do even more with it
> >
> >
> >
> >
> > On Wed, Jul 17, 2019 at 7:07 AM Elek, Marton <el...@apache.org> wrote:
> >
> > > Hi,
> > >
> > > Github UI (ui!) helps to merge Pull Requests to the proposed branch.
> > > There are three different ways to do it [1]:
> > >
> > > 1. Keep all the different commits from the PR branch and create one
> > > additional merge commit ("Create a merge commit")
> > >
> > > 2. Squash all the commits and commit the change as one patch ("Squash
> > > and merge")
> > >
> > > 3. Keep all the different commits from the PR branch but rebase, merge
> > > commit will be missing ("Rebase and merge")
> > >
> > >
> > >
> > > As only the option 2 is compatible with the existing development
> > > practices of Hadoop (1 issue = 1 patch = 1 commit), I call for a lazy
> > > consensus vote: If no objections withing 3 days, I will ask INFRA to
> > > disable the options 1 and 3 to make the process less error prone.
> > >
> > > Please let me know, what do you think,
> > >
> > > Thanks a lot
> > > Marton
> > >
> > > ps: Personally I prefer to merge from local as it enables to sign the
> > > commits and do a final build before push. But this is a different
> story,
> > > this proposal is only about removing the options which are obviously
> > > risky...
> > >
> > > ps2: You can always do any kind of merge / commits from CLI, for
> example
> > > to merge a feature branch together with keeping the history.
> > >
> > > [1]:
> > >
> > >
> >
> https://help.github.com/en/articles/merging-a-pull-request#merging-a-pull-request-on-github
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> > >
> > >
> >
>