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) < nore...@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) < ste...@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 <ste...@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 <aajis...@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 <aajis...@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-unsubscr...@hadoop.apache.org >> For additional commands, e-mail: common-dev-h...@hadoop.apache.org >> >>
