Hi Mathieu, Jacques, inline...
Am 28.01.20 um 20:31 schrieb Mathieu Lirzin:
Hello Jacques, "jler...@apache.org" <jler...@apache.org> writes:This is in relation with "Github PRs and Jira" thread (https://markmail.org/message/s422zuivbmzglph4) Below is my 1st experience of GitHub PR merge in the context of ASF dual hosting with GitBox. So I somehow made a jump in the void...
...
After reviewing the change I picked "squash and merge PR" among the 3 GitHub PR merge options. Because I did not want to break the linear Git flow, it seemed the best option. But despite "squashing" we got 3 commits; 2 from Daniel Watford and one from I. I don't know if it's possible to do otherwise with the 2 other options. Maybe it's good to know that Daniel contributed... Also I expected that my comment in GitHub would be used as the final commit comment. So I then tried to amend the commit by modifying ONLY the comment, and then push comment after a pull. But I got a fast-forward issue and after trying several pull and push tricks I understood I'll never pass over this issue: "[remote rejected] trunk -> trunk (pre-receive hook declined)" Because it's related to having "receive.denynonfastforwards" set to true on GitBox server[1] and I don't want to annoy Infra to temporary set it true for a such change.One must never, never, never rewrite history of the trunk branch. :-)
+1 !I like to add that I appreciate experiments and learning, especially if the experience is shared like Jacques did.
It should not affect the official repositories though. ...
Also we can ask our contributors to use in the PRs title the format of our commit template. For instance in[2] instead of OFBIZ-11331: Allow ComponentContainerTest to run on windows rather Fixed: Allow ComponentContainerTest to run on windows (OFBIZ-11331) Then the commit/s would contain the explanations. I just fear we will have sometimes to explain, and ask contributors to edit their comments or titles... I'll sleep on it and wait for comments before doing any additions or changes in our documentation about that, in relation with the "Github PRs and Jira" threadI think it would be better to not use the PR feature as long as there is not a community consensus that this is an acceptable contribution channel. As stated previously I am not against adopting Github PR *if and only if* we have a plan to move out of Jira. Given the pile of existing policies, I don't think this is a good idea to simply provide more contribution options/policies, I think it is important to review existing ones and consider replacing some of them.
+1 for these statements.
For example we could deprecate patch based contribution, or at least adopt the ‘git format-patch’ conventions.
Not sure if we necessarily have to deprecate the patch based contributions. It could be a simpler way for contributors to provide a change, especially if they are not developers and/or familiar with the pull request mechanisms. Maybe the patch based way becomes obsolete naturally but I would not force it.
We should work out a simple, documented way how to do it with PR's and encourage contributors to use it, including using proper commit statements following our template to prevent doing correctional work on the committers site.
Thanks, Michael Brohl ecomify GmbH - www.ecomify.de
smime.p7s
Description: S/MIME Cryptographic Signature
