Github and GitBox are inconsistent

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Github and GitBox are inconsistent

Akira Ajisaka-4
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Github and GitBox are inconsistent

Steve Loughran-4
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Github and GitBox are inconsistent

Steve Loughran-4
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) <
[hidden email]>" [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) <
[hidden email]>" [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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
Reply | Threaded
Open this post in threaded view
|

Proposal: Force 'squash and merge' on github UI

Elek, Marton
In reply to this post by Steve Loughran-4
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Akira Ajisaka-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]