Yes, once confirmed that the branch builds fine on our Jenkins, we should do the "squash and merge". (we should already be happy with a proper PR) My experience so far was like you describe, but it doesn't explain why Elliotte causes "github" to become the committer. One possible difference I see is that he's both the author and committer. I never push my commits via github, but always via gitbox.
Robert On 14-3-2020 04:14:18, Olivier Lamy <ol...@apache.org> wrote: I agree we must make it mandatory for the committer (us) to squash it. But not really mandatory to ask contributor to squash but just only use the "Squash and merge" option and you will get proper commit on merge: see this commit https://github.com/apache/maven-javadoc-plugin/commit/f92b508c26945a0e728fb3b49e87fe216401c9c1 On Sat, 14 Mar 2020 at 01:26, Karl Heinz Marbaise wrote: > Hi, > > On 13.03.20 15:58, Michael Osipov wrote: > > Am 2020-03-12 um 19:46 schrieb Robert Scholte: > >> This week I was very surprised to see commits from the user call > >> "github" in Jenkins: > >> > https://builds.apache.org/job/maven-box/job/maven-shared-utils/job/master/changes > >> > >> > >> > >> IMO we shouldn't want these kind of commits. > >> Based on the most recent activities I had a chat with Sylwester en > >> Elliotte. > >> > >> The reason is the author of these commits was Elliotte, but the > >> committer Github > >> > https://gitbox.apache.org/repos/asf?p=maven-shared-utils.git&a=commit&h=8ed3e6827885a161a8802100f0f50968555356b0 > >> > >> > >> > >> Elliotte tried to figure it out, and his conclusion was that in case > >> he squashed and merged commits via github, the committer became github. > >> > >> If this is indeed the case, we should always ask the author to squash > >> his commits so we can track the commit better, and it makes it easier > >> to find possible regressions (and revert them when necessary) > >> > >> Not sure if this would help, but my WOW is creating a patch from > >> github, and applying it to the gitBOX url. Squashing and merging it > >> from here would at least make me the committer. > > > > I highly dislike the squash feature in GitHub because you are out of > > control of the process. Only, Maven committers, shall be in the > > committer field. Third parties are not trustworthy for me. > > > > Me process for the last couple of years with PRs was > > > > * Request a squash from a submitter > > * Pull that branch into my local clone > > * Run tests (locally, Jenkins) > > * Adjust message > > * Merge into master > > * Push > > > > This gives me full control before this is written to remote. I simply > > don't trust GH, especially not with these ugly merge commits. > > > > M > > > > If I pick a PR from GitHub I simply using the command line instructions... > > I do a `git commit --amend` ...(That makes me the committer of the > change)...sometimes needed to fix the commit message... > > Pushing for testing on Jenkins ...and afterwards merging the single > commit back to master (no merge commits)... > > > Also what happens here several times is this: (Just an example: > maven-artifact-transfer): > > commit 3338744598e195454f4c5ed1187ea192adfbcf97 > Author: Piotrek Żygieło > Commit: Piotrek Żygieło > > Remove unused field > > So this makes it impossible to check who has integrated that patch into > the code base... > > Or as a different example: > > commit a80f5cc026da0e3d98ec720b363728f4509293ff > Author: Maarten Mulders > Commit: Karl Heinz Marbaise > > [MDEP-626] Upgrade struts and xerces due to CVEs > o This newer version doesn't depend on struts2-core or xercesImpl. > o Upgrade Doxia and add doxia-core > > > That shows exactly who has merged that...and who the committer was... > > Just my 2 cents. > > Kind regards > Karl Heinz Marbaise > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
