You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mapreduce-dev@hadoop.apache.org by "Elek, Marton" <el...@apache.org> on 2019/03/04 15:42:02 UTC

Proposal: Force 'squash and merge' on github UI

I don't know which one is the best approach, personally I prefer to
merge locally as in that case the commit can be signed by my local key.

Github PR can be closed with adding a "Closes #412" comment to the end
of the commit message and with this comment the final commit will be
linked under to original PR>


Using the merge button also can be good if we use 'squash and merge' option.

With the simple 'merge' option we would have more complex history
(additional merge commits) and with 'rebase' we would have multiple
small commits for one Jira.

I think the 'squash and merge' option is in sync with the existing
practice and I propose to disable to the two other options to make it
easier to choose the right option for the "press-to-merge" approach.

What do you think?
Marton


On 3/4/19 12:44 PM, Steve Loughran wrote:
> thanks
> 
> I'm just starting to play with/understand the integration, and think we
> should start worrying about "what makes a good process here"
> 
> while I like the idea of a "press-to-merge" button, it's not going to do
> the whitespace stripping on a merge we ought to be doing and it gets signed
> by the github GPG key, rather than any private key which some but not
> enough of us use.
> 
> Similarly: where do discussions go, how best to review, etc, etc.
> 
> I've got no idea of best practises here. Some experience of the spark
> process, which has
> 
> * A template for the PR text which is automatically used to initialize the
> text
> * strict use of reviewers demanding everything right (no
> committer-final-cleanup)
> * the ability of trusted people to ask jenkins to run tests etc
> 
> 1. Any other ASF projects to look at?
> 2. who fancies trying to define a process here on a confluence page?
> 
> 
> 
> 
> On Mon, Mar 4, 2019 at 8:05 AM Akira Ajisaka <aa...@gmail.com> wrote:
> 
>> This issue was fixed by ASF infra team.
>> If there are any problems, please let me know.
>>
>> Regards,
>> Akira
>>
>> On Mon, Mar 4, 2019 at 3:25 PM Akira Ajisaka <aa...@gmail.com> wrote:
>>>
>>> Hi folks,
>>>
>>> I found github and gitbox are inconsistent and filed
>>> https://issues.apache.org/jira/browse/INFRA-17947 to fix it.
>>>
>>> Regards,
>>> Akira
>>
>> ---------------------------------------------------------------------
>> 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: Proposal: Force 'squash and merge' on github UI

Posted by Akira Ajisaka <aa...@apache.org>.
Thanks Elek for your proposal.

I'm +1 for disabling 'merge' and 'rebase and merge' buttons in the
GitHub repository.

-Akira

On Tue, Mar 5, 2019 at 12:42 AM Elek, Marton <el...@apache.org> wrote:
>
> I don't know which one is the best approach, personally I prefer to
> merge locally as in that case the commit can be signed by my local key.
>
> Github PR can be closed with adding a "Closes #412" comment to the end
> of the commit message and with this comment the final commit will be
> linked under to original PR>
>
>
> Using the merge button also can be good if we use 'squash and merge' option.
>
> With the simple 'merge' option we would have more complex history
> (additional merge commits) and with 'rebase' we would have multiple
> small commits for one Jira.
>
> I think the 'squash and merge' option is in sync with the existing
> practice and I propose to disable to the two other options to make it
> easier to choose the right option for the "press-to-merge" approach.
>
> What do you think?
> Marton
>
>
> On 3/4/19 12:44 PM, Steve Loughran wrote:
> > thanks
> >
> > I'm just starting to play with/understand the integration, and think we
> > should start worrying about "what makes a good process here"
> >
> > while I like the idea of a "press-to-merge" button, it's not going to do
> > the whitespace stripping on a merge we ought to be doing and it gets signed
> > by the github GPG key, rather than any private key which some but not
> > enough of us use.
> >
> > Similarly: where do discussions go, how best to review, etc, etc.
> >
> > I've got no idea of best practises here. Some experience of the spark
> > process, which has
> >
> > * A template for the PR text which is automatically used to initialize the
> > text
> > * strict use of reviewers demanding everything right (no
> > committer-final-cleanup)
> > * the ability of trusted people to ask jenkins to run tests etc
> >
> > 1. Any other ASF projects to look at?
> > 2. who fancies trying to define a process here on a confluence page?
> >
> >
> >
> >
> > On Mon, Mar 4, 2019 at 8:05 AM Akira Ajisaka <aa...@gmail.com> wrote:
> >
> >> This issue was fixed by ASF infra team.
> >> If there are any problems, please let me know.
> >>
> >> Regards,
> >> Akira
> >>
> >> On Mon, Mar 4, 2019 at 3:25 PM Akira Ajisaka <aa...@gmail.com> wrote:
> >>>
> >>> Hi folks,
> >>>
> >>> I found github and gitbox are inconsistent and filed
> >>> https://issues.apache.org/jira/browse/INFRA-17947 to fix it.
> >>>
> >>> Regards,
> >>> Akira
> >>
> >> ---------------------------------------------------------------------
> >> 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
>

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


Re: Proposal: Force 'squash and merge' on github UI

Posted by Akira Ajisaka <aa...@apache.org>.
Thanks Elek for your proposal.

I'm +1 for disabling 'merge' and 'rebase and merge' buttons in the
GitHub repository.

-Akira

On Tue, Mar 5, 2019 at 12:42 AM Elek, Marton <el...@apache.org> wrote:
>
> I don't know which one is the best approach, personally I prefer to
> merge locally as in that case the commit can be signed by my local key.
>
> Github PR can be closed with adding a "Closes #412" comment to the end
> of the commit message and with this comment the final commit will be
> linked under to original PR>
>
>
> Using the merge button also can be good if we use 'squash and merge' option.
>
> With the simple 'merge' option we would have more complex history
> (additional merge commits) and with 'rebase' we would have multiple
> small commits for one Jira.
>
> I think the 'squash and merge' option is in sync with the existing
> practice and I propose to disable to the two other options to make it
> easier to choose the right option for the "press-to-merge" approach.
>
> What do you think?
> Marton
>
>
> On 3/4/19 12:44 PM, Steve Loughran wrote:
> > thanks
> >
> > I'm just starting to play with/understand the integration, and think we
> > should start worrying about "what makes a good process here"
> >
> > while I like the idea of a "press-to-merge" button, it's not going to do
> > the whitespace stripping on a merge we ought to be doing and it gets signed
> > by the github GPG key, rather than any private key which some but not
> > enough of us use.
> >
> > Similarly: where do discussions go, how best to review, etc, etc.
> >
> > I've got no idea of best practises here. Some experience of the spark
> > process, which has
> >
> > * A template for the PR text which is automatically used to initialize the
> > text
> > * strict use of reviewers demanding everything right (no
> > committer-final-cleanup)
> > * the ability of trusted people to ask jenkins to run tests etc
> >
> > 1. Any other ASF projects to look at?
> > 2. who fancies trying to define a process here on a confluence page?
> >
> >
> >
> >
> > On Mon, Mar 4, 2019 at 8:05 AM Akira Ajisaka <aa...@gmail.com> wrote:
> >
> >> This issue was fixed by ASF infra team.
> >> If there are any problems, please let me know.
> >>
> >> Regards,
> >> Akira
> >>
> >> On Mon, Mar 4, 2019 at 3:25 PM Akira Ajisaka <aa...@gmail.com> wrote:
> >>>
> >>> Hi folks,
> >>>
> >>> I found github and gitbox are inconsistent and filed
> >>> https://issues.apache.org/jira/browse/INFRA-17947 to fix it.
> >>>
> >>> Regards,
> >>> Akira
> >>
> >> ---------------------------------------------------------------------
> >> 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
>

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


Re: Proposal: Force 'squash and merge' on github UI

Posted by Akira Ajisaka <aa...@apache.org>.
Thanks Elek for your proposal.

I'm +1 for disabling 'merge' and 'rebase and merge' buttons in the
GitHub repository.

-Akira

On Tue, Mar 5, 2019 at 12:42 AM Elek, Marton <el...@apache.org> wrote:
>
> I don't know which one is the best approach, personally I prefer to
> merge locally as in that case the commit can be signed by my local key.
>
> Github PR can be closed with adding a "Closes #412" comment to the end
> of the commit message and with this comment the final commit will be
> linked under to original PR>
>
>
> Using the merge button also can be good if we use 'squash and merge' option.
>
> With the simple 'merge' option we would have more complex history
> (additional merge commits) and with 'rebase' we would have multiple
> small commits for one Jira.
>
> I think the 'squash and merge' option is in sync with the existing
> practice and I propose to disable to the two other options to make it
> easier to choose the right option for the "press-to-merge" approach.
>
> What do you think?
> Marton
>
>
> On 3/4/19 12:44 PM, Steve Loughran wrote:
> > thanks
> >
> > I'm just starting to play with/understand the integration, and think we
> > should start worrying about "what makes a good process here"
> >
> > while I like the idea of a "press-to-merge" button, it's not going to do
> > the whitespace stripping on a merge we ought to be doing and it gets signed
> > by the github GPG key, rather than any private key which some but not
> > enough of us use.
> >
> > Similarly: where do discussions go, how best to review, etc, etc.
> >
> > I've got no idea of best practises here. Some experience of the spark
> > process, which has
> >
> > * A template for the PR text which is automatically used to initialize the
> > text
> > * strict use of reviewers demanding everything right (no
> > committer-final-cleanup)
> > * the ability of trusted people to ask jenkins to run tests etc
> >
> > 1. Any other ASF projects to look at?
> > 2. who fancies trying to define a process here on a confluence page?
> >
> >
> >
> >
> > On Mon, Mar 4, 2019 at 8:05 AM Akira Ajisaka <aa...@gmail.com> wrote:
> >
> >> This issue was fixed by ASF infra team.
> >> If there are any problems, please let me know.
> >>
> >> Regards,
> >> Akira
> >>
> >> On Mon, Mar 4, 2019 at 3:25 PM Akira Ajisaka <aa...@gmail.com> wrote:
> >>>
> >>> Hi folks,
> >>>
> >>> I found github and gitbox are inconsistent and filed
> >>> https://issues.apache.org/jira/browse/INFRA-17947 to fix it.
> >>>
> >>> Regards,
> >>> Akira
> >>
> >> ---------------------------------------------------------------------
> >> 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
>

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


Re: Proposal: Force 'squash and merge' on github UI

Posted by Akira Ajisaka <aa...@apache.org>.
Thanks Elek for your proposal.

I'm +1 for disabling 'merge' and 'rebase and merge' buttons in the
GitHub repository.

-Akira

On Tue, Mar 5, 2019 at 12:42 AM Elek, Marton <el...@apache.org> wrote:
>
> I don't know which one is the best approach, personally I prefer to
> merge locally as in that case the commit can be signed by my local key.
>
> Github PR can be closed with adding a "Closes #412" comment to the end
> of the commit message and with this comment the final commit will be
> linked under to original PR>
>
>
> Using the merge button also can be good if we use 'squash and merge' option.
>
> With the simple 'merge' option we would have more complex history
> (additional merge commits) and with 'rebase' we would have multiple
> small commits for one Jira.
>
> I think the 'squash and merge' option is in sync with the existing
> practice and I propose to disable to the two other options to make it
> easier to choose the right option for the "press-to-merge" approach.
>
> What do you think?
> Marton
>
>
> On 3/4/19 12:44 PM, Steve Loughran wrote:
> > thanks
> >
> > I'm just starting to play with/understand the integration, and think we
> > should start worrying about "what makes a good process here"
> >
> > while I like the idea of a "press-to-merge" button, it's not going to do
> > the whitespace stripping on a merge we ought to be doing and it gets signed
> > by the github GPG key, rather than any private key which some but not
> > enough of us use.
> >
> > Similarly: where do discussions go, how best to review, etc, etc.
> >
> > I've got no idea of best practises here. Some experience of the spark
> > process, which has
> >
> > * A template for the PR text which is automatically used to initialize the
> > text
> > * strict use of reviewers demanding everything right (no
> > committer-final-cleanup)
> > * the ability of trusted people to ask jenkins to run tests etc
> >
> > 1. Any other ASF projects to look at?
> > 2. who fancies trying to define a process here on a confluence page?
> >
> >
> >
> >
> > On Mon, Mar 4, 2019 at 8:05 AM Akira Ajisaka <aa...@gmail.com> wrote:
> >
> >> This issue was fixed by ASF infra team.
> >> If there are any problems, please let me know.
> >>
> >> Regards,
> >> Akira
> >>
> >> On Mon, Mar 4, 2019 at 3:25 PM Akira Ajisaka <aa...@gmail.com> wrote:
> >>>
> >>> Hi folks,
> >>>
> >>> I found github and gitbox are inconsistent and filed
> >>> https://issues.apache.org/jira/browse/INFRA-17947 to fix it.
> >>>
> >>> Regards,
> >>> Akira
> >>
> >> ---------------------------------------------------------------------
> >> 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
>

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