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