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 Akira Ajisaka <aa...@gmail.com> on 2019/03/04 06:25:04 UTC
Github and GitBox are inconsistent
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: 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: 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: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-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
Proposal: Force 'squash and merge' on github UI
Posted by "Elek, Marton" <el...@apache.org>.
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: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Proposal: Force 'squash and merge' on github UI
Posted by "Elek, Marton" <el...@apache.org>.
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
Proposal: Force 'squash and merge' on github UI
Posted by "Elek, Marton" <el...@apache.org>.
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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Github and GitBox are inconsistent
Posted by Steve Loughran <st...@cloudera.com.INVALID>.
Update, you can use the github web editor to remove whitespace, as done in
https://github.com/apache/hadoop/pull/539
but as that's a hadoop-aws module, it still needs a client pull and retest.
If you do a git pull from your own private branch which formed the PR,
those edits come back down, signed with the github GPG key & with me listed
as the --author.
* gpg: Signature made Mon 4 Mar 11:54:27 2019 GMT
| gpg: using RSA key 4AEE18F83AFDEB23
| gpg: Good signature from "GitHub (web-flow commit signing) <
noreply@github.com>" [full]
| 9ed42911c18 - (HEAD -> s3/HADOOP-16109-parquet-eof-s3a-seek,
github/s3/HADOOP-16109-parquet-eof-s3a-seek) ITestS3AContractSeek.java (4
minutes ago)
* gpg: Signature made Thu 28 Feb 19:44:03 2019 GMT
| gpg: using RSA key 38237EE425050285077DB57AD22CF846DBB162A0
| gpg: Good signature from "Steve Loughran (ASF code sign key - 2018) <
stevel@apache.org>" [ultimate]
| gpg: aka "[jpeg image of size 8070]" [ultimate]
| cada0c26671 - HADOOP-16109. Use parameterized tests for the s3a seek
contract, with all three seek options checked (4 days ago)
This does mean that for PRs where the submitter has set the "allow edits"
button, it would be possible for the reviewer to fix the whitespace before
the commit, but that still sucks. Now, if we have hadoop-yetus do the fix
FWIW, AW recommends yetus's smart apply dev-support/bin/smart-apply-patch
https://effectivemachines.com/2018/05/23/applying-patches-smartly-using-apache-yetus/
I should be able to locally D/L and apply the patch, with whitespace fix,
from:
smart-apply-patch --project=hadoop --committer --gpg-sign GH:539
If this works well, maybe should just mandate that this is the mechanism
for PRs to be merged in.
On Mon, Mar 4, 2019 at 11:44 AM Steve Loughran <st...@cloudera.com> 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
>>
>>
Proposal: Force 'squash and merge' on github UI
Posted by "Elek, Marton" <el...@apache.org>.
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
Re: Github and GitBox are inconsistent
Posted by Steve Loughran <st...@cloudera.com.INVALID>.
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
>
>
Re: Github and GitBox are inconsistent
Posted by Akira Ajisaka <aa...@gmail.com>.
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: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: Github and GitBox are inconsistent
Posted by Akira Ajisaka <aa...@gmail.com>.
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: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: Github and GitBox are inconsistent
Posted by Akira Ajisaka <aa...@gmail.com>.
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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Github and GitBox are inconsistent
Posted by Akira Ajisaka <aa...@gmail.com>.
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