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 > > >
