Hi Pierre,
I don't want to put more burden on the committer size either. From my experience, if we want to continue to use our commit template using PR merge is
not an option.
Jacques
Le 29/01/2020 à 09:05, Pierre Smits a écrit :
I agree with Micheal here that the project should not impose restrictions
on how non-privileged provide their enhancements.
Indeed, those helping non-privileged contributors should be helped to do
their part as easy as possible.
Best regards,
Pierre Smits
*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer
On Wed, Jan 29, 2020 at 8:02 AM Michael Brohl <michael.br...@ecomify.de>
wrote:
Hi Jacques,
inline...
Am 28.01.20 um 19:05 schrieb jler...@apache.org:
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.
But I really wanted to change the commit comment to follow our
template. So I decided to pull rebase, slightly change the
ComponentContainerTest class, commit and push. Hence I created a new
commit, somehow a duplicate of the PR merge, at least with a correctly
formatted comment.
This was an awkward experience, I don't know if i could have done it
better, ideas, advices?
Maybe advising contributors to use our template in commit comments
used by GitHub PRs?
Also we can ask our contributors to use in the PRs title the format of
our commit template. For instance in[2] instead of
I would go so far to make the proper use of the templates a restriction
to get the PR into the codebase. We should make the committer's work as
easy as possible.
...
Thanks,
Michael Brohl
ecomify GmbH - www.ecomify.de
