Hi All, I have completed the first draft of the Contributing via Git & Github (WIP) <https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=145724011> page. And it is now available for review.
Please review and let the community know what you think needs to be: 1. added 2. deleted 3. explained better 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 Fri, Jan 31, 2020 at 3:53 PM Pierre Smits <pierresm...@apache.org> wrote: > Pull Requests can be handled in the local development of the committer the > same way as patch files. Whereas a committer would create a new test branch > in his local clone and apply a patch file to evaluate the changes, the > process regarding Pull Request can be considered as easier. > > Pull Request available on Github can be seen in the local clone. In order > to have this working, the following line should be added to the git > configuration of the local clone: > > fetch = +refs/pull/*/head:refs/remotes/origin/pr/* > > > Preferably this line should exist before the 'fetch = > +refs/heads/*:refs/remotes/origin/*' of the 'Github' remote. > > The committer can check out the Pull Request into his local clone from the > Github repository and review in accordance with the committer conventions > and protocols. If need be, he can apply the slight changes, add > additional commits of his own through cherry-picking and commit the whole > with a commit-message in accordance with the template and then merge into > the appropriate official OFBiz branche(s). And after that, push what needs > to be pushed to the official OFBiz repo. > > A Pull Request can also be closed without a merges into any of the > branches in the official repositories, but this must be done in Github as > it is not a git feature. > > Btw and IMO, it is better that committers also have their git setup work > with the repos on GitHub instead of Gitbox. The ASF git services will > ensure that both are kept in sync. > > 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 Fri, Jan 31, 2020 at 2:59 PM Nicolas Malin <nicolas.ma...@nereide.fr> > wrote: > >> Nice thread and sharing :) >> >> I retain that the must important idea is keep the historic commit with >> high quality. >> >> My vision is we can let all contributer to create some PR with a "bad" >> branch quality, this permit to follow the historic link to this PR. The >> merge on trunk will be done with the commiter touch to realize the >> squashing and set the comment related. >> >> I didn't think that we can validate directly a PR, because if it's done, >> this indicate that the contributer as "a commiter level" concerning the >> commit quality. Then it's a fact that the community rules has been learn >> and apply, good way to become a commiter. >> >> I understand the same idea on the RocketQM documentation concerning a PR >> merge to trunk. >> >> So, I'm in favor the let all PR with only one rule for the submit, >> create an issue on Jira as Daniel Watford done with issue OFBIZ-11330 >> [1]. In other word, create your PR as you want, just initialize an issue >> for step down to a commiter that will finish the merge (as a code keeper). >> >> Nicolas >> >> [1] https://issues.apache.org/jira/browse/OFBIZ-11330 >> >> On 31/01/2020 10:23, Pierre Smits wrote: >> > Thank you, Jacopo, for bringing forward the approach of Apache >> RocketMQ. I >> > will add that reference to the Contributing via Git & Github (WIP) >> > < >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=145724011 >> > >> > page >> > so that it isn't forgotten. >> > >> > >> > >> > 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 Fri, Jan 31, 2020 at 10:00 AM Jacopo Cappellato < >> > jacopo.cappell...@gmail.com> wrote: >> > >> >> I am happy we are having this conversation because, once finalized, we >> will >> >> optimize our usage of Git (and GitHub)! >> >> >> >> On this topic, I like the workflow and the documentation provided by >> one of >> >> the other Apache project, RocketQM: >> >> https://rocketmq.apache.org/docs/pull-request/ >> >> >> >> In my opinion we could follow a similar approach and provide similar >> >> documentation to our contributors and committers. >> >> >> >> Jacopo >> >> >> >> >> >> On Thu, Jan 30, 2020 at 5:10 PM Michael Brohl < >> michael.br...@ecomify.de> >> >> wrote: >> >> >> >>> I mean squashing in the sense of pulling several commits together in a >> >>> single commit (with a quality commit message). This could also be a >> diff >> >>> which is applied as a patch manually. I am not just referring to the >> >>> GitHub function. >> >>> >> >>> I really don't want to see all kinds of exotic messages coming up in >> our >> >>> commit history. >> >>> >> >>> If the workflow allows rejecting a pull request because of bad commit >> >>> messages or maybe a hundred commits for a change, I would also be fine >> >>> with it. >> >>> >> >>> My main point is that I'm a bit worried about quality because it is >> much >> >>> easier to pull in a pull request instead of applying a patch. >> >>> >> >>> Applying a patch also results in a single commit and the committer can >> >>> handle the message while a pull request maybe results in several >> commits >> >>> each with its own message which are in the hands of the contributor. >> >>> Applying a patch and changing things where necessary is also easier >> >>> because you can clearly see the changed files in your sandbox ("your >> >>> slightly midified patch is in trunk r..."). >> >>> >> >>> If I am not wrong, accepting a pull request does a forward merge >> >>> directly so you have to find the locations again where you want to >> make >> >>> changes. >> >>> >> >>> I guess reverting will also be more difficult if the pull request >> >>> contains more than one commit. >> >>> >> >>> It *could* be reasonable to request single commit pull requests to >> avoid >> >>> all this, leaving the work to "squash" and write quality commit >> messages >> >>> up to the contributor. >> >>> >> >>> I am not against using PR's but I also worry about the downsides and >> >>> additional work for contributors dealing with them. >> >>> >> >>> Thanks, >> >>> >> >>> Michael Brohl >> >>> >> >>> ecomify GmbH - www.ecomify.de >> >>> >> >>> >> >>> Am 30.01.20 um 16:33 schrieb Jacques Le Roux: >> >>>> At 1st glance, based on my experience with squashing I tend to agree >> >>>> >> >>>> Jacques >> >>>> >> >>>> Le 30/01/2020 à 16:04, Pierre Smits a écrit : >> >>>>> Having 'quality commit message' should not pose a problem when >> >>>>> contributors >> >>>>> (authors) apply the template for their commit message. >> >>>>> >> >>>>> See as an example the messages of the commit I have in pull request >> >>>>> #2 in >> >>>>> ofbiz-plugins (https://github.com/apache/ofbiz-plugins/pull/2). >> >>>>> >> >>>>> The question is whether a commit message like in >> >>>>> https://github.com/apache/ofbiz-plugins/pull/1 would be rejected. >> >>>>> >> >>>>> AFAIUI, the issue with squashing commits is, when they are shared >> with >> >>>>> others, that history will be rewritten and thus causing trouble for >> >> the >> >>>>> other parties. >> >>>>> IMO, squashing should not occur when a pull request has been issued. >> >>>>> >> >>>>> >> >>>>> 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 Thu, Jan 30, 2020 at 3:42 PM Michael Brohl < >> >> michael.br...@ecomify.de >> >>>>> wrote: >> >>>>> >> >>>>>> Just a quick thought because I currently cannot dig deeper: >> >>>>>> >> >>>>>> We should also have a workflow (or better: requirement) to either >> >> write >> >>>>>> quality commit messages for every commit or squash changes and >> have a >> >>>>>> quality commit message for the resulting commit. If people do a lot >> >> of >> >>>>>> commits during their work on a change, we might not want to have >> all >> >>>>>> these commits in our project history. >> >>>>>> >> >>>>>> Regards, >> >>>>>> >> >>>>>> Michael Brohl >> >>>>>> >> >>>>>> ecomify GmbH - www.ecomify.de >> >>>>>> >> >>>>>> >> >>>>>> Am 30.01.20 um 14:25 schrieb Pierre Smits: >> >>>>>>> Hi All, >> >>>>>>> >> >>>>>>> Recently we saw some postings in various threads how to deal with >> >>>>>>> commits >> >>>>>>> from contributors coming via pull requests in Github. >> >>>>>>> If I understand it correctly, the issue we're dealing with has to >> >>>>>>> do with >> >>>>>>> the commit message (as defined in >> >>>>>>> >> >> >> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+commit+message+template >> >>>>>>> ). >> >>>>>>> After a code contribution has been accepted by a committer, this >> >>>>>>> commit >> >>>>>>> message appears in: >> >>>>>>> >> >>>>>>> 1. the OFBiz repo >> >>>>>>> 2. a posting to the commit@ mailing list >> >>>>>>> 3. in the referenced JIRA ticket (as a comment, and in the >> >> commit >> >>>>>>> section, see e.g. >> >>>>>>> https://issues.apache.org/jira/browse/OFBIZ-10954) >> >>>>>>> >> >>>>>>> Elements of the commit message are also used in the regularly >> >>>>>>> occurring >> >>>>>>> blog posts of the project. >> >>>>>>> >> >>>>>>> With our repositories available via Github, we can expect that >> more >> >>>>>>> and >> >>>>>>> more contributors work within their local clones, and publish >> their >> >>>>>>> code >> >>>>>>> changes (commits) in their own public forks on Github and from >> there >> >>>>>> issue >> >>>>>>> a pull request to get these contributions evaluated by community >> >>>>>>> members >> >>>>>>> and when good incorporated into the OFBiz repositories. >> >>>>>>> >> >>>>>>> A pull request can contain one or more commits (from the >> >>>>>>> contributor - or >> >>>>>>> in git parlance: the author). >> >>>>>>> >> >>>>>>> So, when the commit message by the contributor (author) of each of >> >> his >> >>>>>>> commits is formatted in accordance with the commit-message >> template >> >>>>>>> there >> >>>>>>> is nothing that stands in the way to take it to the next step. >> >>>>>>> Which is >> >>>>>> the >> >>>>>>> evaluation of the contribution by other community members. >> >>>>>>> >> >>>>>>> Is my assessment so far correct? >> >>>>>>> >> >>>>>>> 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 >> >>>>>>> >> >>> >> >
