You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Pierre Smits <pi...@apache.org> on 2020/01/30 13:25:00 UTC
OFBiz contributions & Github Pull Requests
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
Re: OFBiz contributions & Github Pull Requests
Posted by Pierre Smits <pi...@apache.org>.
FWIW: I have started a related WIP page in confluence, to capture all
relating aspects/issues. See
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=145724011
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 2:25 PM Pierre Smits <pi...@apache.org> wrote:
> 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
>
Re: OFBiz contributions & Github Pull Requests
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thank you Pierre and Daniel,
I have to reviewed things in detail, but the Github PR templates could be a workflow changer
Jacques
Le 30/01/2020 à 15:12, Pierre Smits a écrit :
> Thanks Daniel,
>
> This could indeed be useful. The project already has a template for the
> commit message (see
> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+commit+message+template),
> which is currently used by all committers.
>
> Working through/via Git (and pull requests via Github) indicates that all
> contributors (authors) apply this template to get the commit message
> properly formatted.
>
> 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:03 PM Daniel Watford <da...@foomoo.co.uk> wrote:
>
>> Hello Pierre,
>>
>> Its not something I've worked with before, but git commit message templates
>> might help here.
>>
>> From a quick scan of the git documentation it seems that the
>> config.template configuration item can be used to specify a file to use as
>> a template. (
>> https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration)
>>
>> This could be augmented with a git pre-commit hook to examine the commit
>> message to ensure it is considered valid. (
>> https://git-scm.com/docs/githooks
>> )
>> The hooks are bash scripts, so there might be some issues with
>> compatibility on windows.
>>
>> The problem with above approaches is that they are controlled by the
>> environment's configuration rather than the content of the repository.
>> There might be a solution based around having gradle set configure.message
>> on .git/config and copy the pre-commit hook to .git/hooks/, but that might
>> be considered poor practice to have build scripts changing the developer's
>> environment.
>>
>> Github PR templates might be of interest -
>>
>> https://help.github.com/en/github/building-a-strong-community/creating-a-pull-request-template-for-your-repository
>>
>> Thanks,
>>
>> Dan.
>>
>> On Thu, 30 Jan 2020 at 13:25, Pierre Smits <pi...@apache.org> wrote:
>>
>>> 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
>>>
>>
>> --
>> Daniel Watford
>>
Re: OFBiz contributions & Github Pull Requests
Posted by Pierre Smits <pi...@apache.org>.
Thanks Daniel,
This could indeed be useful. The project already has a template for the
commit message (see
https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+commit+message+template),
which is currently used by all committers.
Working through/via Git (and pull requests via Github) indicates that all
contributors (authors) apply this template to get the commit message
properly formatted.
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:03 PM Daniel Watford <da...@foomoo.co.uk> wrote:
> Hello Pierre,
>
> Its not something I've worked with before, but git commit message templates
> might help here.
>
> From a quick scan of the git documentation it seems that the
> config.template configuration item can be used to specify a file to use as
> a template. (
> https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration)
>
> This could be augmented with a git pre-commit hook to examine the commit
> message to ensure it is considered valid. (
> https://git-scm.com/docs/githooks
> )
> The hooks are bash scripts, so there might be some issues with
> compatibility on windows.
>
> The problem with above approaches is that they are controlled by the
> environment's configuration rather than the content of the repository.
> There might be a solution based around having gradle set configure.message
> on .git/config and copy the pre-commit hook to .git/hooks/, but that might
> be considered poor practice to have build scripts changing the developer's
> environment.
>
> Github PR templates might be of interest -
>
> https://help.github.com/en/github/building-a-strong-community/creating-a-pull-request-template-for-your-repository
>
> Thanks,
>
> Dan.
>
> On Thu, 30 Jan 2020 at 13:25, Pierre Smits <pi...@apache.org> wrote:
>
> > 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
> >
>
>
> --
> Daniel Watford
>
Re: OFBiz contributions & Github Pull Requests
Posted by Daniel Watford <da...@foomoo.co.uk>.
Hello Pierre,
Its not something I've worked with before, but git commit message templates
might help here.
From a quick scan of the git documentation it seems that the
config.template configuration item can be used to specify a file to use as
a template. (
https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration)
This could be augmented with a git pre-commit hook to examine the commit
message to ensure it is considered valid. (https://git-scm.com/docs/githooks
)
The hooks are bash scripts, so there might be some issues with
compatibility on windows.
The problem with above approaches is that they are controlled by the
environment's configuration rather than the content of the repository.
There might be a solution based around having gradle set configure.message
on .git/config and copy the pre-commit hook to .git/hooks/, but that might
be considered poor practice to have build scripts changing the developer's
environment.
Github PR templates might be of interest -
https://help.github.com/en/github/building-a-strong-community/creating-a-pull-request-template-for-your-repository
Thanks,
Dan.
On Thu, 30 Jan 2020 at 13:25, Pierre Smits <pi...@apache.org> wrote:
> 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
>
--
Daniel Watford
Re: OFBiz contributions & Github Pull Requests
Posted by Jacopo Cappellato <ja...@gmail.com>.
My preference is to lean on GitHub because it is an accepted and common way
for ASF projects to get contributions and because it is very popular among
contributors.
There are still many details (including the one about PR mentioned by
Michael) to fine tune but I am confident that we will find a good solution
for them.
Jacopo
On Thu, Feb 13, 2020 at 8:03 AM Michael Brohl <mi...@ecomify.de>
wrote:
> There is one drawback with PR's I just noticed: the commits of the pull
> requests will be written to the commit history using the timestamp of
> the original commits.
>
> So if the commits were written a month ago and a committer merges in the
> codebase now, it appears in the history a month ago.
>
> This might be confusing, at least when retracing problems or following
> changes.
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Michael Brohl
> Geschäftsführer
>
> Fon +49 521 448 157-91
> Fax +49 521 448 157-99
> Mobil +49 160 3664918
> Xing xing.com/profile/Michael_Brohl
> LinkedIn linkedin.com/in/michaelbrohl
>
> Company and Management Headquarters:
> ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
> Fon: +49 521 448157-90, Fax: +49 521 448157-99, www.ecomify.de
>
> Court Registration: Amtsgericht Bielefeld HRB 41683
> Chief Executive Officer: Martin Becker, Michael Brohl
>
> 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
> >
>
>
Re: OFBiz contributions & Github Pull Requests
Posted by Pierre Smits <pi...@apache.org>.
Currently, a change to the codebase and contributed through a PullRequest
(and patch files too) need to be manually reviewed (vetted) and tested by
privileged contributors. Fortunately with PullRequests, part of the vetting
is done through the integration of Sonarcloud (see the comment in the PR,
e.g. https://github.com/apache/ofbiz-framework/pull/14).
Testing of a PR (to see whether it breaks the code, passes the integration
tests) can also be done before a privileged contributor does his thing. The
PullRequest can be checked out by the CI and subsequently build the
check-out and run the integration tests. And the result of such can be
added as a comment to the PR.
Then either the author reworks his contribution (when SonarCloud quality
gates weren't passed, or build or test flaws appears), or the privileged
contributor merges the commit into the appropriate branch(es).
For the project, this would mean a workload reduction, and an opportunity
(for everyone) to focus on on the more important stuff.
Best regards,
Pierre Smits
*Proud* *contributor* (but without privileges)* of* Apache OFBiz
<https://ofbiz.apache.org/>, since 2008
*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer
On Thu, Feb 13, 2020 at 11:18 AM Daniel Watford <da...@foomoo.co.uk> wrote:
> Hi Michael,
>
> Those are the commits from my feature branch, coming in as a consequence of
> merging my PR.
>
> I imagine merging PRs from contributors will always run into this issue.
>
> One possible solution would be for a committer to checkout the PR (branch),
> generate a patch file, and then apply the patch to their own trunk branch.
>
> This would allow the committer a chance to affect the commit comments too,
> and would have the same effect as squashing a lot of commits.
>
> I'm sure there would be some git magic plus scripting to accomplish this,
> potentially collecting the comments from the PR commits as presenting them
> to the committer as a suggested commit message.
>
> The downside is that PRs wouldn't be merged as the contributions they carry
> would have been merged via a different channel.
>
> Dan.
>
> On Thu, 13 Feb 2020 at 10:04, Michael Brohl <mi...@ecomify.de>
> wrote:
>
> > Hi Nicolas,
> >
> > your are correct, I checked the history again and this seems to work
> > fine, using the committed date for the history. Thank you for the
> > explanation.
> >
> > While checking I found another thing which confuses me: there are
> > commits in the history which seem not to be from an OFBiz committer
> > (hope I did not miss anything here).
> >
> > Please see the screenshot here:
> >
> >
> https://share.ecomify.de/download.php?id=3&token=4dmjDN050Jz1q0I1uvI4foUdW8ZhxnTT
> >
> >
> > Looks like commits from another branch, see the non-linear history.
> > Maybe Jacques has an explanation for it?
> >
> > Thanks,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > Am 13.02.20 um 10:40 schrieb Nicolas Malin:
> > > Hi,
> > >
> > > On 13/02/2020 08:03, Michael Brohl wrote:
> > >> There is one drawback with PR's I just noticed: the commits of the
> > >> pull requests will be written to the commit history using the
> > >> timestamp of the original commits.
> > >>
> > >> So if the commits were written a month ago and a committer merges in
> > >> the codebase now, it appears in the history a month ago.
> > > Michael, you have an example of this case ?
> > >
> > > Normally, when you merge or cherry pick, we have two dates, author date
> > > (commit origin) and the commit date. If I check the git history with
> the
> > > last Jacques's commit by PR I found :
> > >
> > > $ git log --pretty=fuller -n1
> > e1e1a4813d05f236ea851c729d3b01f5c2ff44a4
> > > commit e1e1a4813d05f236ea851c729d3b01f5c2ff44a4 (HEAD -> trunk,
> > > origin/trunk, origin/HEAD)
> > > Author: Pierre Smits <pi...@apache.org>
> > > AuthorDate: Tue Feb 11 10:24:10 2020 +0100
> > > Commit: Jacques Le Roux <ja...@les7arts.com>
> > > CommitDate: Wed Feb 12 12:09:34 2020 +0100
> > >
> > > By default, the author date is displaying and the commit date is use to
> > > ordering.
> > >
> > > Nicolas
> > >
> > >> This might be confusing, at least when retracing problems or following
> > >> changes.
> > >>
> > >> Michael Brohl
> > >>
> > >> ecomify GmbH - www.ecomify.de
> > >>
> > >>
> > >> Michael Brohl
> > >> Geschäftsführer
> > >>
> > >> Fon +49 521 448 157-91
> > >> Fax +49 521 448 157-99
> > >> Mobil +49 160 3664918
> > >> Xing xing.com/profile/Michael_Brohl
> > >> LinkedIn linkedin.com/in/michaelbrohl
> > >>
> > >> Company and Management Headquarters:
> > >> ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
> > >> Fon: +49 521 448157-90, Fax: +49 521 448157-99, www.ecomify.de
> > >>
> > >> Court Registration: Amtsgericht Bielefeld HRB 41683
> > >> Chief Executive Officer: Martin Becker, Michael Brohl
> > >>
> > >> 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
> > >>>
> >
> >
>
> --
> Daniel Watford
>
Re: OFBiz contributions & Github Pull Requests
Posted by Pierre Smits <pi...@apache.org>.
Currently, notifications regarding a PullRequest are only sent to a
selected few in our community, nor do they appear to be referenced in the
appropriate ticket(s). This is not a good thing as it deprives the rest of
the community of the opportunity to collaborate.
We should work to get this improved. Who will take the lead (together with
INFRA, if need be)?
Best regards,
Pierre Smits
*Proud* *contributor* (but without privileges)* of* Apache OFBiz
<https://ofbiz.apache.org/>, since 2008
*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer
On Thu, Feb 13, 2020 at 12:02 PM Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Thanks Daniel,
>
> I think the best (for now at least) is to follow the advices (WIP) of the
> special page we have for that in wiki[1]
>
> This is what I have in my local config:
>
> [remote "origin"]
> url = https://gitbox.apache.org/repos/asf/ofbiz-framework.git
> fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
> fetch = +refs/heads/*:refs/remotes/origin/*
>
> Then I have all the PRs at hand and I can cherry-pick changes from remote
> PR branches and commit/push then directly
>
> We get something like
> https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;a=commit;h=e1e1a4813d05f236ea851c729d3b01f5c2ff44a4
>
> How does that show in your tree Michael? Last time, the one your image
> shows, on GitHub I did a PR squash and merge, which is surely not the best
> way.
>
> Jacques
>
> [1]
>
> https://cwiki.apache.org/confluence/display/OFBIZ/Contributing+via+Git+and+Github++-+WIP#ContributingviaGitandGithub-WIP-HandlingaPullRequest(forcommitters)
>
>
> Le 13/02/2020 à 11:18, Daniel Watford a écrit :
> > Hi Michael,
> >
> > Those are the commits from my feature branch, coming in as a consequence
> of
> > merging my PR.
> >
> > I imagine merging PRs from contributors will always run into this issue.
> >
> > One possible solution would be for a committer to checkout the PR
> (branch),
> > generate a patch file, and then apply the patch to their own trunk
> branch.
> >
> > This would allow the committer a chance to affect the commit comments
> too,
> > and would have the same effect as squashing a lot of commits.
> >
> > I'm sure there would be some git magic plus scripting to accomplish this,
> > potentially collecting the comments from the PR commits as presenting
> them
> > to the committer as a suggested commit message.
> >
> > The downside is that PRs wouldn't be merged as the contributions they
> carry
> > would have been merged via a different channel.
> >
> > Dan.
> >
> > On Thu, 13 Feb 2020 at 10:04, Michael Brohl <mi...@ecomify.de>
> > wrote:
> >
> >> Hi Nicolas,
> >>
> >> your are correct, I checked the history again and this seems to work
> >> fine, using the committed date for the history. Thank you for the
> >> explanation.
> >>
> >> While checking I found another thing which confuses me: there are
> >> commits in the history which seem not to be from an OFBiz committer
> >> (hope I did not miss anything here).
> >>
> >> Please see the screenshot here:
> >>
> >>
> https://share.ecomify.de/download.php?id=3&token=4dmjDN050Jz1q0I1uvI4foUdW8ZhxnTT
> >>
> >>
> >> Looks like commits from another branch, see the non-linear history.
> >> Maybe Jacques has an explanation for it?
> >>
> >> Thanks,
> >>
> >> Michael Brohl
> >>
> >> ecomify GmbH - www.ecomify.de
> >>
> >>
> >> Am 13.02.20 um 10:40 schrieb Nicolas Malin:
> >>> Hi,
> >>>
> >>> On 13/02/2020 08:03, Michael Brohl wrote:
> >>>> There is one drawback with PR's I just noticed: the commits of the
> >>>> pull requests will be written to the commit history using the
> >>>> timestamp of the original commits.
> >>>>
> >>>> So if the commits were written a month ago and a committer merges in
> >>>> the codebase now, it appears in the history a month ago.
> >>> Michael, you have an example of this case ?
> >>>
> >>> Normally, when you merge or cherry pick, we have two dates, author date
> >>> (commit origin) and the commit date. If I check the git history with
> the
> >>> last Jacques's commit by PR I found :
> >>>
> >>> $ git log --pretty=fuller -n1
> >> e1e1a4813d05f236ea851c729d3b01f5c2ff44a4
> >>> commit e1e1a4813d05f236ea851c729d3b01f5c2ff44a4 (HEAD -> trunk,
> >>> origin/trunk, origin/HEAD)
> >>> Author: Pierre Smits <pi...@apache.org>
> >>> AuthorDate: Tue Feb 11 10:24:10 2020 +0100
> >>> Commit: Jacques Le Roux <ja...@les7arts.com>
> >>> CommitDate: Wed Feb 12 12:09:34 2020 +0100
> >>>
> >>> By default, the author date is displaying and the commit date is use to
> >>> ordering.
> >>>
> >>> Nicolas
> >>>
> >>>> This might be confusing, at least when retracing problems or following
> >>>> changes.
> >>>>
> >>>> Michael Brohl
> >>>>
> >>>> ecomify GmbH - www.ecomify.de
> >>>>
> >>>>
> >>>> Michael Brohl
> >>>> Geschäftsführer
> >>>>
> >>>> Fon +49 521 448 157-91
> >>>> Fax +49 521 448 157-99
> >>>> Mobil +49 160 3664918
> >>>> Xing xing.com/profile/Michael_Brohl
> >>>> LinkedIn linkedin.com/in/michaelbrohl
> >>>>
> >>>> Company and Management Headquarters:
> >>>> ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
> >>>> Fon: +49 521 448157-90, Fax: +49 521 448157-99, www.ecomify.de
> >>>>
> >>>> Court Registration: Amtsgericht Bielefeld HRB 41683
> >>>> Chief Executive Officer: Martin Becker, Michael Brohl
> >>>>
> >>>> 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
> >>>>>
> >>
>
Re: OFBiz contributions & Github Pull Requests
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks Daniel,
I think the best (for now at least) is to follow the advices (WIP) of the special page we have for that in wiki[1]
This is what I have in my local config:
[remote "origin"]
url = https://gitbox.apache.org/repos/asf/ofbiz-framework.git
fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
fetch = +refs/heads/*:refs/remotes/origin/*
Then I have all the PRs at hand and I can cherry-pick changes from remote PR branches and commit/push then directly
We get something like https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;a=commit;h=e1e1a4813d05f236ea851c729d3b01f5c2ff44a4
How does that show in your tree Michael? Last time, the one your image shows, on GitHub I did a PR squash and merge, which is surely not the best way.
Jacques
[1]
https://cwiki.apache.org/confluence/display/OFBIZ/Contributing+via+Git+and+Github++-+WIP#ContributingviaGitandGithub-WIP-HandlingaPullRequest(forcommitters)
Le 13/02/2020 à 11:18, Daniel Watford a écrit :
> Hi Michael,
>
> Those are the commits from my feature branch, coming in as a consequence of
> merging my PR.
>
> I imagine merging PRs from contributors will always run into this issue.
>
> One possible solution would be for a committer to checkout the PR (branch),
> generate a patch file, and then apply the patch to their own trunk branch.
>
> This would allow the committer a chance to affect the commit comments too,
> and would have the same effect as squashing a lot of commits.
>
> I'm sure there would be some git magic plus scripting to accomplish this,
> potentially collecting the comments from the PR commits as presenting them
> to the committer as a suggested commit message.
>
> The downside is that PRs wouldn't be merged as the contributions they carry
> would have been merged via a different channel.
>
> Dan.
>
> On Thu, 13 Feb 2020 at 10:04, Michael Brohl <mi...@ecomify.de>
> wrote:
>
>> Hi Nicolas,
>>
>> your are correct, I checked the history again and this seems to work
>> fine, using the committed date for the history. Thank you for the
>> explanation.
>>
>> While checking I found another thing which confuses me: there are
>> commits in the history which seem not to be from an OFBiz committer
>> (hope I did not miss anything here).
>>
>> Please see the screenshot here:
>>
>> https://share.ecomify.de/download.php?id=3&token=4dmjDN050Jz1q0I1uvI4foUdW8ZhxnTT
>>
>>
>> Looks like commits from another branch, see the non-linear history.
>> Maybe Jacques has an explanation for it?
>>
>> Thanks,
>>
>> Michael Brohl
>>
>> ecomify GmbH - www.ecomify.de
>>
>>
>> Am 13.02.20 um 10:40 schrieb Nicolas Malin:
>>> Hi,
>>>
>>> On 13/02/2020 08:03, Michael Brohl wrote:
>>>> There is one drawback with PR's I just noticed: the commits of the
>>>> pull requests will be written to the commit history using the
>>>> timestamp of the original commits.
>>>>
>>>> So if the commits were written a month ago and a committer merges in
>>>> the codebase now, it appears in the history a month ago.
>>> Michael, you have an example of this case ?
>>>
>>> Normally, when you merge or cherry pick, we have two dates, author date
>>> (commit origin) and the commit date. If I check the git history with the
>>> last Jacques's commit by PR I found :
>>>
>>> $ git log --pretty=fuller -n1
>> e1e1a4813d05f236ea851c729d3b01f5c2ff44a4
>>> commit e1e1a4813d05f236ea851c729d3b01f5c2ff44a4 (HEAD -> trunk,
>>> origin/trunk, origin/HEAD)
>>> Author: Pierre Smits <pi...@apache.org>
>>> AuthorDate: Tue Feb 11 10:24:10 2020 +0100
>>> Commit: Jacques Le Roux <ja...@les7arts.com>
>>> CommitDate: Wed Feb 12 12:09:34 2020 +0100
>>>
>>> By default, the author date is displaying and the commit date is use to
>>> ordering.
>>>
>>> Nicolas
>>>
>>>> This might be confusing, at least when retracing problems or following
>>>> changes.
>>>>
>>>> Michael Brohl
>>>>
>>>> ecomify GmbH - www.ecomify.de
>>>>
>>>>
>>>> Michael Brohl
>>>> Geschäftsführer
>>>>
>>>> Fon +49 521 448 157-91
>>>> Fax +49 521 448 157-99
>>>> Mobil +49 160 3664918
>>>> Xing xing.com/profile/Michael_Brohl
>>>> LinkedIn linkedin.com/in/michaelbrohl
>>>>
>>>> Company and Management Headquarters:
>>>> ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
>>>> Fon: +49 521 448157-90, Fax: +49 521 448157-99, www.ecomify.de
>>>>
>>>> Court Registration: Amtsgericht Bielefeld HRB 41683
>>>> Chief Executive Officer: Martin Becker, Michael Brohl
>>>>
>>>> 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
>>>>>
>>
Re: OFBiz contributions & Github Pull Requests
Posted by Daniel Watford <da...@foomoo.co.uk>.
Hi Michael,
Those are the commits from my feature branch, coming in as a consequence of
merging my PR.
I imagine merging PRs from contributors will always run into this issue.
One possible solution would be for a committer to checkout the PR (branch),
generate a patch file, and then apply the patch to their own trunk branch.
This would allow the committer a chance to affect the commit comments too,
and would have the same effect as squashing a lot of commits.
I'm sure there would be some git magic plus scripting to accomplish this,
potentially collecting the comments from the PR commits as presenting them
to the committer as a suggested commit message.
The downside is that PRs wouldn't be merged as the contributions they carry
would have been merged via a different channel.
Dan.
On Thu, 13 Feb 2020 at 10:04, Michael Brohl <mi...@ecomify.de>
wrote:
> Hi Nicolas,
>
> your are correct, I checked the history again and this seems to work
> fine, using the committed date for the history. Thank you for the
> explanation.
>
> While checking I found another thing which confuses me: there are
> commits in the history which seem not to be from an OFBiz committer
> (hope I did not miss anything here).
>
> Please see the screenshot here:
>
> https://share.ecomify.de/download.php?id=3&token=4dmjDN050Jz1q0I1uvI4foUdW8ZhxnTT
>
>
> Looks like commits from another branch, see the non-linear history.
> Maybe Jacques has an explanation for it?
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 13.02.20 um 10:40 schrieb Nicolas Malin:
> > Hi,
> >
> > On 13/02/2020 08:03, Michael Brohl wrote:
> >> There is one drawback with PR's I just noticed: the commits of the
> >> pull requests will be written to the commit history using the
> >> timestamp of the original commits.
> >>
> >> So if the commits were written a month ago and a committer merges in
> >> the codebase now, it appears in the history a month ago.
> > Michael, you have an example of this case ?
> >
> > Normally, when you merge or cherry pick, we have two dates, author date
> > (commit origin) and the commit date. If I check the git history with the
> > last Jacques's commit by PR I found :
> >
> > $ git log --pretty=fuller -n1
> e1e1a4813d05f236ea851c729d3b01f5c2ff44a4
> > commit e1e1a4813d05f236ea851c729d3b01f5c2ff44a4 (HEAD -> trunk,
> > origin/trunk, origin/HEAD)
> > Author: Pierre Smits <pi...@apache.org>
> > AuthorDate: Tue Feb 11 10:24:10 2020 +0100
> > Commit: Jacques Le Roux <ja...@les7arts.com>
> > CommitDate: Wed Feb 12 12:09:34 2020 +0100
> >
> > By default, the author date is displaying and the commit date is use to
> > ordering.
> >
> > Nicolas
> >
> >> This might be confusing, at least when retracing problems or following
> >> changes.
> >>
> >> Michael Brohl
> >>
> >> ecomify GmbH - www.ecomify.de
> >>
> >>
> >> Michael Brohl
> >> Geschäftsführer
> >>
> >> Fon +49 521 448 157-91
> >> Fax +49 521 448 157-99
> >> Mobil +49 160 3664918
> >> Xing xing.com/profile/Michael_Brohl
> >> LinkedIn linkedin.com/in/michaelbrohl
> >>
> >> Company and Management Headquarters:
> >> ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
> >> Fon: +49 521 448157-90, Fax: +49 521 448157-99, www.ecomify.de
> >>
> >> Court Registration: Amtsgericht Bielefeld HRB 41683
> >> Chief Executive Officer: Martin Becker, Michael Brohl
> >>
> >> 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
> >>>
>
>
--
Daniel Watford
Re: OFBiz contributions & Github Pull Requests
Posted by Michael Brohl <mi...@ecomify.de>.
Hi Nicolas,
your are correct, I checked the history again and this seems to work
fine, using the committed date for the history. Thank you for the
explanation.
While checking I found another thing which confuses me: there are
commits in the history which seem not to be from an OFBiz committer
(hope I did not miss anything here).
Please see the screenshot here:
https://share.ecomify.de/download.php?id=3&token=4dmjDN050Jz1q0I1uvI4foUdW8ZhxnTT
Looks like commits from another branch, see the non-linear history.
Maybe Jacques has an explanation for it?
Thanks,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 13.02.20 um 10:40 schrieb Nicolas Malin:
> Hi,
>
> On 13/02/2020 08:03, Michael Brohl wrote:
>> There is one drawback with PR's I just noticed: the commits of the
>> pull requests will be written to the commit history using the
>> timestamp of the original commits.
>>
>> So if the commits were written a month ago and a committer merges in
>> the codebase now, it appears in the history a month ago.
> Michael, you have an example of this case ?
>
> Normally, when you merge or cherry pick, we have two dates, author date
> (commit origin) and the commit date. If I check the git history with the
> last Jacques's commit by PR I found :
>
> $ git log --pretty=fuller -n1 e1e1a4813d05f236ea851c729d3b01f5c2ff44a4
> commit e1e1a4813d05f236ea851c729d3b01f5c2ff44a4 (HEAD -> trunk,
> origin/trunk, origin/HEAD)
> Author: Pierre Smits <pi...@apache.org>
> AuthorDate: Tue Feb 11 10:24:10 2020 +0100
> Commit: Jacques Le Roux <ja...@les7arts.com>
> CommitDate: Wed Feb 12 12:09:34 2020 +0100
>
> By default, the author date is displaying and the commit date is use to
> ordering.
>
> Nicolas
>
>> This might be confusing, at least when retracing problems or following
>> changes.
>>
>> Michael Brohl
>>
>> ecomify GmbH - www.ecomify.de
>>
>>
>> Michael Brohl
>> Geschäftsführer
>>
>> Fon +49 521 448 157-91
>> Fax +49 521 448 157-99
>> Mobil +49 160 3664918
>> Xing xing.com/profile/Michael_Brohl
>> LinkedIn linkedin.com/in/michaelbrohl
>>
>> Company and Management Headquarters:
>> ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
>> Fon: +49 521 448157-90, Fax: +49 521 448157-99, www.ecomify.de
>>
>> Court Registration: Amtsgericht Bielefeld HRB 41683
>> Chief Executive Officer: Martin Becker, Michael Brohl
>>
>> 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
>>>
Re: OFBiz contributions & Github Pull Requests
Posted by Nicolas Malin <ni...@nereide.fr>.
Hi,
On 13/02/2020 08:03, Michael Brohl wrote:
> There is one drawback with PR's I just noticed: the commits of the
> pull requests will be written to the commit history using the
> timestamp of the original commits.
>
> So if the commits were written a month ago and a committer merges in
> the codebase now, it appears in the history a month ago.
Michael, you have an example of this case ?
Normally, when you merge or cherry pick, we have two dates, author date
(commit origin) and the commit date. If I check the git history with the
last Jacques's commit by PR I found :
$ git log --pretty=fuller -n1 e1e1a4813d05f236ea851c729d3b01f5c2ff44a4
commit e1e1a4813d05f236ea851c729d3b01f5c2ff44a4 (HEAD -> trunk,
origin/trunk, origin/HEAD)
Author: Pierre Smits <pi...@apache.org>
AuthorDate: Tue Feb 11 10:24:10 2020 +0100
Commit: Jacques Le Roux <ja...@les7arts.com>
CommitDate: Wed Feb 12 12:09:34 2020 +0100
By default, the author date is displaying and the commit date is use to
ordering.
Nicolas
>
> This might be confusing, at least when retracing problems or following
> changes.
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Michael Brohl
> Geschäftsführer
>
> Fon +49 521 448 157-91
> Fax +49 521 448 157-99
> Mobil +49 160 3664918
> Xing xing.com/profile/Michael_Brohl
> LinkedIn linkedin.com/in/michaelbrohl
>
> Company and Management Headquarters:
> ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
> Fon: +49 521 448157-90, Fax: +49 521 448157-99, www.ecomify.de
>
> Court Registration: Amtsgericht Bielefeld HRB 41683
> Chief Executive Officer: Martin Becker, Michael Brohl
>
> 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
>>
>
Re: OFBiz contributions & Github Pull Requests
Posted by Michael Brohl <mi...@ecomify.de>.
There is one drawback with PR's I just noticed: the commits of the pull
requests will be written to the commit history using the timestamp of
the original commits.
So if the commits were written a month ago and a committer merges in the
codebase now, it appears in the history a month ago.
This might be confusing, at least when retracing problems or following
changes.
Michael Brohl
ecomify GmbH - www.ecomify.de
Michael Brohl
Geschäftsführer
Fon +49 521 448 157-91
Fax +49 521 448 157-99
Mobil +49 160 3664918
Xing xing.com/profile/Michael_Brohl
LinkedIn linkedin.com/in/michaelbrohl
Company and Management Headquarters:
ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
Fon: +49 521 448157-90, Fax: +49 521 448157-99, www.ecomify.de
Court Registration: Amtsgericht Bielefeld HRB 41683
Chief Executive Officer: Martin Becker, Michael Brohl
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
>
Re: OFBiz contributions & Github Pull Requests
Posted by Pierre Smits <pi...@apache.org>.
Hi all,
In this thread we discussed improvements to the Contributing via Git and
Github page in Confluence (see [1]). Some were then adamant that the page
should have the WIP status referenced in the subject/title.
However, since then the page hasn't changed. If nothing comes forward in
the coming days, I will remove the WIP status from the subject/title. After
that, contributors can continue to improve the page, like they can improve
any other page that doesn't have the WIP status in the subject/title
[1]
https://cwiki.apache.org/confluence/display/OFBIZ/Contributing+via+Git+and+Github+-+WIP
Met vriendelijke groet,
Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer
On Sat, Feb 22, 2020 at 10:12 AM Michael Brohl <mi...@ecomify.de>
wrote:
> It seems you just removed the work in progess notes from the page
> without waiting for the review I've announced.
>
> The page should be marked as WIP until we agree on the processes
> described there, IMO.
>
> Thanks,
>
> Michael
>
>
> Am 22.02.20 um 08:59 schrieb Pierre Smits:
> > @Michal,
> >
> > Your comments have been addressed and noted. You can continue to review,
> > discuss and suggest changes...
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor* (but unfortunately without privileges)* of* Apache
> > OFBiz <https://ofbiz.apache.org/>, since 2008
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> > On Fri, Feb 21, 2020 at 9:24 AM Michael Brohl <mi...@ecomify.de>
> > wrote:
> >
> >> I made a comment just yesterday. The page needs review and this might
> >> take some time.
> >>
> >> Michael
> >>
> >>
> >> Am 21.02.20 um 09:20 schrieb Pierre Smits:
> >>> Hi All,
> >>>
> >>> It seems feedback on the 'Contributing via Git and Github' page in our
> >> wiki
> >>> has subsided. Shortly I will apply lazy consensus to remove its WiP
> >> status.
> >>> Met vriendelijke groet,
> >>>
> >>> Pierre Smits
> >>> *Proud* *contributor* (but unfortunately without privileges)* of*
> Apache
> >>> OFBiz <https://ofbiz.apache.org/>, since 2008
> >>>
> >>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>> Apache Incubator <https://incubator.apache.org>, committer
> >>> Apache Steve <https://steve.apache.org>, committer
> >>>
> >>>
> >>> On Fri, Feb 14, 2020 at 1:55 PM Jacques Le Roux <
> >>> jacques.le.roux@les7arts.com> wrote:
> >>>
> >>>> +1
> >>>>
> >>>> Jacques
> >>>>
> >>>> Le 14/02/2020 à 12:29, Pierre Smits a écrit :
> >>>>> Hi Nicolas,
> >>>>>
> >>>>> Your suggestion to show only open PRs is way better.
> >>>>>
> >>>>> I will update the page.
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Pierre Smits
> >>>>> *Proud* *contributor* (but without privileges)* of* Apache OFBiz
> >>>>> <https://ofbiz.apache.org/>, since 2008
> >>>>>
> >>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>>>> Apache Incubator <https://incubator.apache.org>, committer
> >>>>> Apache Steve <https://steve.apache.org>, committer
> >>>>>
> >>>>>
> >>>>> On Fri, Feb 14, 2020 at 12:15 PM Nicolas Malin <
> >> nicolas.malin@nereide.fr
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>> On 31/01/2020 15:53, Pierre Smits wrote:
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>> After some tries I propose to use
> >>>>>>
> >>>>>> fetch = +refs/pull/*/merge:refs/remotes/pr/*
> >>>>>>
> >>>>>> instead of
> >>>>>>
> >>>>>> fetch = +refs/pull/**/head:refs/remotes/origin/pr/**
> >>>>>>
> >>>>>> The first list pull request available to merge, and the second list
> >> all
> >>>>>> pull request (closed included)
> >>>>>>
> >>>>>> Nicolas
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>
>
>
Re: OFBiz contributions & Github Pull Requests
Posted by Michael Brohl <mi...@ecomify.de>.
It seems you just removed the work in progess notes from the page
without waiting for the review I've announced.
The page should be marked as WIP until we agree on the processes
described there, IMO.
Thanks,
Michael
Am 22.02.20 um 08:59 schrieb Pierre Smits:
> @Michal,
>
> Your comments have been addressed and noted. You can continue to review,
> discuss and suggest changes...
>
> Met vriendelijke groet,
>
> Pierre Smits
> *Proud* *contributor* (but unfortunately without privileges)* of* Apache
> OFBiz <https://ofbiz.apache.org/>, since 2008
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> Apache Steve <https://steve.apache.org>, committer
>
>
> On Fri, Feb 21, 2020 at 9:24 AM Michael Brohl <mi...@ecomify.de>
> wrote:
>
>> I made a comment just yesterday. The page needs review and this might
>> take some time.
>>
>> Michael
>>
>>
>> Am 21.02.20 um 09:20 schrieb Pierre Smits:
>>> Hi All,
>>>
>>> It seems feedback on the 'Contributing via Git and Github' page in our
>> wiki
>>> has subsided. Shortly I will apply lazy consensus to remove its WiP
>> status.
>>> Met vriendelijke groet,
>>>
>>> Pierre Smits
>>> *Proud* *contributor* (but unfortunately without privileges)* of* Apache
>>> OFBiz <https://ofbiz.apache.org/>, since 2008
>>>
>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
>>> *Apache Directory <https://directory.apache.org>, PMC Member*
>>> Apache Incubator <https://incubator.apache.org>, committer
>>> Apache Steve <https://steve.apache.org>, committer
>>>
>>>
>>> On Fri, Feb 14, 2020 at 1:55 PM Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>>> +1
>>>>
>>>> Jacques
>>>>
>>>> Le 14/02/2020 à 12:29, Pierre Smits a écrit :
>>>>> Hi Nicolas,
>>>>>
>>>>> Your suggestion to show only open PRs is way better.
>>>>>
>>>>> I will update the page.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>> *Proud* *contributor* (but without privileges)* of* Apache OFBiz
>>>>> <https://ofbiz.apache.org/>, since 2008
>>>>>
>>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
>>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
>>>>> Apache Incubator <https://incubator.apache.org>, committer
>>>>> Apache Steve <https://steve.apache.org>, committer
>>>>>
>>>>>
>>>>> On Fri, Feb 14, 2020 at 12:15 PM Nicolas Malin <
>> nicolas.malin@nereide.fr
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>> On 31/01/2020 15:53, Pierre Smits wrote:
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> After some tries I propose to use
>>>>>>
>>>>>> fetch = +refs/pull/*/merge:refs/remotes/pr/*
>>>>>>
>>>>>> instead of
>>>>>>
>>>>>> fetch = +refs/pull/**/head:refs/remotes/origin/pr/**
>>>>>>
>>>>>> The first list pull request available to merge, and the second list
>> all
>>>>>> pull request (closed included)
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
Re: OFBiz contributions & Github Pull Requests
Posted by Pierre Smits <pi...@apache.org>.
@Michal,
Your comments have been addressed and noted. You can continue to review,
discuss and suggest changes...
Met vriendelijke groet,
Pierre Smits
*Proud* *contributor* (but unfortunately without privileges)* of* Apache
OFBiz <https://ofbiz.apache.org/>, since 2008
*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer
On Fri, Feb 21, 2020 at 9:24 AM Michael Brohl <mi...@ecomify.de>
wrote:
> I made a comment just yesterday. The page needs review and this might
> take some time.
>
> Michael
>
>
> Am 21.02.20 um 09:20 schrieb Pierre Smits:
> > Hi All,
> >
> > It seems feedback on the 'Contributing via Git and Github' page in our
> wiki
> > has subsided. Shortly I will apply lazy consensus to remove its WiP
> status.
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor* (but unfortunately without privileges)* of* Apache
> > OFBiz <https://ofbiz.apache.org/>, since 2008
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> > On Fri, Feb 14, 2020 at 1:55 PM Jacques Le Roux <
> > jacques.le.roux@les7arts.com> wrote:
> >
> >> +1
> >>
> >> Jacques
> >>
> >> Le 14/02/2020 à 12:29, Pierre Smits a écrit :
> >>> Hi Nicolas,
> >>>
> >>> Your suggestion to show only open PRs is way better.
> >>>
> >>> I will update the page.
> >>>
> >>> Thanks!
> >>>
> >>> Best regards,
> >>>
> >>> Pierre Smits
> >>> *Proud* *contributor* (but without privileges)* of* Apache OFBiz
> >>> <https://ofbiz.apache.org/>, since 2008
> >>>
> >>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>> Apache Incubator <https://incubator.apache.org>, committer
> >>> Apache Steve <https://steve.apache.org>, committer
> >>>
> >>>
> >>> On Fri, Feb 14, 2020 at 12:15 PM Nicolas Malin <
> nicolas.malin@nereide.fr
> >>>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>> On 31/01/2020 15:53, Pierre Smits wrote:
> >>>>
> >>>> 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.
> >>>>
> >>>> After some tries I propose to use
> >>>>
> >>>> fetch = +refs/pull/*/merge:refs/remotes/pr/*
> >>>>
> >>>> instead of
> >>>>
> >>>> fetch = +refs/pull/**/head:refs/remotes/origin/pr/**
> >>>>
> >>>> The first list pull request available to merge, and the second list
> all
> >>>> pull request (closed included)
> >>>>
> >>>> Nicolas
> >>>>
> >>>>
> >>>>
> >>>>
>
>
Re: OFBiz contributions & Github Pull Requests
Posted by Michael Brohl <mi...@ecomify.de>.
I made a comment just yesterday. The page needs review and this might
take some time.
Michael
Am 21.02.20 um 09:20 schrieb Pierre Smits:
> Hi All,
>
> It seems feedback on the 'Contributing via Git and Github' page in our wiki
> has subsided. Shortly I will apply lazy consensus to remove its WiP status.
>
> Met vriendelijke groet,
>
> Pierre Smits
> *Proud* *contributor* (but unfortunately without privileges)* of* Apache
> OFBiz <https://ofbiz.apache.org/>, since 2008
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> Apache Steve <https://steve.apache.org>, committer
>
>
> On Fri, Feb 14, 2020 at 1:55 PM Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> +1
>>
>> Jacques
>>
>> Le 14/02/2020 à 12:29, Pierre Smits a écrit :
>>> Hi Nicolas,
>>>
>>> Your suggestion to show only open PRs is way better.
>>>
>>> I will update the page.
>>>
>>> Thanks!
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>> *Proud* *contributor* (but without privileges)* of* Apache OFBiz
>>> <https://ofbiz.apache.org/>, since 2008
>>>
>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
>>> *Apache Directory <https://directory.apache.org>, PMC Member*
>>> Apache Incubator <https://incubator.apache.org>, committer
>>> Apache Steve <https://steve.apache.org>, committer
>>>
>>>
>>> On Fri, Feb 14, 2020 at 12:15 PM Nicolas Malin <nicolas.malin@nereide.fr
>>>
>>> wrote:
>>>
>>>> Hi,
>>>> On 31/01/2020 15:53, Pierre Smits wrote:
>>>>
>>>> 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.
>>>>
>>>> After some tries I propose to use
>>>>
>>>> fetch = +refs/pull/*/merge:refs/remotes/pr/*
>>>>
>>>> instead of
>>>>
>>>> fetch = +refs/pull/**/head:refs/remotes/origin/pr/**
>>>>
>>>> The first list pull request available to merge, and the second list all
>>>> pull request (closed included)
>>>>
>>>> Nicolas
>>>>
>>>>
>>>>
>>>>
Re: OFBiz contributions & Github Pull Requests
Posted by Pierre Smits <pi...@apache.org>.
Hi All,
It seems feedback on the 'Contributing via Git and Github' page in our wiki
has subsided. Shortly I will apply lazy consensus to remove its WiP status.
Met vriendelijke groet,
Pierre Smits
*Proud* *contributor* (but unfortunately without privileges)* of* Apache
OFBiz <https://ofbiz.apache.org/>, since 2008
*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer
On Fri, Feb 14, 2020 at 1:55 PM Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> +1
>
> Jacques
>
> Le 14/02/2020 à 12:29, Pierre Smits a écrit :
> > Hi Nicolas,
> >
> > Your suggestion to show only open PRs is way better.
> >
> > I will update the page.
> >
> > Thanks!
> >
> > Best regards,
> >
> > Pierre Smits
> > *Proud* *contributor* (but without privileges)* of* Apache OFBiz
> > <https://ofbiz.apache.org/>, since 2008
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> > On Fri, Feb 14, 2020 at 12:15 PM Nicolas Malin <nicolas.malin@nereide.fr
> >
> > wrote:
> >
> >> Hi,
> >> On 31/01/2020 15:53, Pierre Smits wrote:
> >>
> >> 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.
> >>
> >> After some tries I propose to use
> >>
> >> fetch = +refs/pull/*/merge:refs/remotes/pr/*
> >>
> >> instead of
> >>
> >> fetch = +refs/pull/**/head:refs/remotes/origin/pr/**
> >>
> >> The first list pull request available to merge, and the second list all
> >> pull request (closed included)
> >>
> >> Nicolas
> >>
> >>
> >>
> >>
>
Re: OFBiz contributions & Github Pull Requests
Posted by Jacques Le Roux <ja...@les7arts.com>.
+1
Jacques
Le 14/02/2020 à 12:29, Pierre Smits a écrit :
> Hi Nicolas,
>
> Your suggestion to show only open PRs is way better.
>
> I will update the page.
>
> Thanks!
>
> Best regards,
>
> Pierre Smits
> *Proud* *contributor* (but without privileges)* of* Apache OFBiz
> <https://ofbiz.apache.org/>, since 2008
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> Apache Steve <https://steve.apache.org>, committer
>
>
> On Fri, Feb 14, 2020 at 12:15 PM Nicolas Malin <ni...@nereide.fr>
> wrote:
>
>> Hi,
>> On 31/01/2020 15:53, Pierre Smits wrote:
>>
>> 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.
>>
>> After some tries I propose to use
>>
>> fetch = +refs/pull/*/merge:refs/remotes/pr/*
>>
>> instead of
>>
>> fetch = +refs/pull/**/head:refs/remotes/origin/pr/**
>>
>> The first list pull request available to merge, and the second list all
>> pull request (closed included)
>>
>> Nicolas
>>
>>
>>
>>
Re: OFBiz contributions & Github Pull Requests
Posted by Pierre Smits <pi...@apache.org>.
Hi Nicolas,
Your suggestion to show only open PRs is way better.
I will update the page.
Thanks!
Best regards,
Pierre Smits
*Proud* *contributor* (but without privileges)* of* Apache OFBiz
<https://ofbiz.apache.org/>, since 2008
*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer
On Fri, Feb 14, 2020 at 12:15 PM Nicolas Malin <ni...@nereide.fr>
wrote:
> Hi,
> On 31/01/2020 15:53, Pierre Smits wrote:
>
> 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.
>
> After some tries I propose to use
>
> fetch = +refs/pull/*/merge:refs/remotes/pr/*
>
> instead of
>
> fetch = +refs/pull/**/head:refs/remotes/origin/pr/**
>
> The first list pull request available to merge, and the second list all
> pull request (closed included)
>
> Nicolas
>
>
>
>
Re: OFBiz contributions & Github Pull Requests
Posted by Nicolas Malin <ni...@nereide.fr>.
Hi,
On 31/01/2020 15:53, Pierre Smits wrote:
> 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.
After some tries I propose to use
fetch = +refs/pull/*/merge:refs/remotes/pr/*
instead of
fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
The first list pull request available to merge, and the second list all
pull request (closed included)
Nicolas
Re: OFBiz contributions & Github Pull Requests
Posted by Pierre Smits <pi...@apache.org>.
One most important +1 for referencing Github over Gitbox is that Pull
Requests are not synced into git-box. Therefore committers can't check that
out that PR from the gitbox repo into a test branch in their local clone.
When preferring gitbox over Github the project is - in essence - saying: if
you (non-privileged contributor) want a privileged contributor to review
and merge your commits into a branch of the official repository you need to
attach patch files, because those without the GitHub location in their
local setup won't see your pull request and thus can't check it out via git.
Another +1 for referencing Github over Gitbox is that a sends a unified
message to all community members (privileged and non-privileged alike) on
what to work with. Furthermore, the current howto for committers (
https://cwiki.apache.org/confluence/display/OFBIZ/Git+for+committers) is
outdated and still references svn, suggesting that svn is still in play,
and keeps the project limping on 2 legs.
We have to keep in mind that many within the greater ASF community and (I
presume those within) the Github organisation regard repositories under the
Apache flag (https://github.com/apache) as official repositories of the
Apache projects.
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 Sat, Feb 8, 2020 at 11:20 AM Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Hi,
>
> I have modified the title to make it more clear (Confluence does not like
> special chars, like &, (, ), you name it...)
>
>
> https://cwiki.apache.org/confluence/display/OFBIZ/Contributing+via+Git+and+Github++-+WIP
>
> I have added a warning about plugins inside framework (no auto sync). I
> added the same about pullAllPluginsSource but Pierre rpreferred we focus
> only
> on Git in this page. So he remove it, I agree.
>
> I fixed some typos
>
> All is here anyway
> https://cwiki.apache.org/confluence/pages/viewpreviousversions.action?pageId=145724011
>
> Now the question is: should we privilege GitHub over GitBox, as advocated
> in this page?
>
> As ever there are 2 faces of the coin:
>
> Pro: easier for PR and to follow GitHub workflow (pragmatic)
>
> Cons: not official, GitHub is only a mirror from ASF POV (theoretical)
>
> Note that some TLP projects are using GitHub as proposed by Jacopo's link
> to Apache Rocket in this page
>
> HTH
>
> Jacques
>
> Le 06/02/2020 à 13:44, Pierre Smits a écrit :
> > 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 <pi...@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.malin@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.cappellato@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.brohl@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.brohl@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
> >>>>>>>>>>
>
Re: OFBiz contributions & Github Pull Requests
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi,
I have modified the title to make it more clear (Confluence does not like special chars, like &, (, ), you name it...)
https://cwiki.apache.org/confluence/display/OFBIZ/Contributing+via+Git+and+Github++-+WIP
I have added a warning about plugins inside framework (no auto sync). I added the same about pullAllPluginsSource but Pierre rpreferred we focus only
on Git in this page. So he remove it, I agree.
I fixed some typos
All is here anyway https://cwiki.apache.org/confluence/pages/viewpreviousversions.action?pageId=145724011
Now the question is: should we privilege GitHub over GitBox, as advocated in this page?
As ever there are 2 faces of the coin:
Pro: easier for PR and to follow GitHub workflow (pragmatic)
Cons: not official, GitHub is only a mirror from ASF POV (theoretical)
Note that some TLP projects are using GitHub as proposed by Jacopo's link to Apache Rocket in this page
HTH
Jacques
Le 06/02/2020 à 13:44, Pierre Smits a écrit :
> 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 <pi...@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 <ni...@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.cappellato@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.brohl@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.brohl@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
>>>>>>>>>>
Re: OFBiz contributions & Github Pull Requests
Posted by Pierre Smits <pi...@apache.org>.
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 <pi...@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 <ni...@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.cappellato@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.brohl@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.brohl@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
>> >>>>>>>
>> >>>
>>
>
Re: OFBiz contributions & Github Pull Requests
Posted by Pierre Smits <pi...@apache.org>.
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 <ni...@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.cappellato@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.brohl@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.brohl@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
> >>>>>>>
> >>>
>
Re: OFBiz contributions & Github Pull Requests
Posted by Nicolas Malin <ni...@nereide.fr>.
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.cappellato@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 <mi...@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.brohl@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
>>>>>>>
>>>
Re: OFBiz contributions & Github Pull Requests
Posted by Pierre Smits <pi...@apache.org>.
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.cappellato@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 <mi...@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.brohl@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
> > >>>>
> > >>>
> >
> >
>
Re: OFBiz contributions & Github Pull Requests
Posted by Jacopo Cappellato <ja...@gmail.com>.
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 <mi...@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.brohl@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
> >>>>
> >>>
>
>
Re: OFBiz contributions & Github Pull Requests
Posted by Pierre Smits <pi...@apache.org>.
Dealing with pull requests in your local git environment can be done in an
easy way, by adding following line to the OFBiz remotes:
fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
preferably before the standard fetch line (fetch =
+refs/heads/*:refs/remotes/origin/*).
This way you can do/have a local checkout for evaluation and testing
purposes, before doing an eventual merge into one of the official branches.
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 6:14 PM Mathieu Lirzin <ma...@nereide.fr>
wrote:
> Michael Brohl <mi...@ecomify.de> writes:
>
> > 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.
>
> +1
>
> I am worried too, Handling pull-requests via Github Web interface makes
> really easy to screw the commit history up.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
>
Re: OFBiz contributions & Github Pull Requests
Posted by Mathieu Lirzin <ma...@nereide.fr>.
Michael Brohl <mi...@ecomify.de> writes:
> 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.
+1
I am worried too, Handling pull-requests via Github Web interface makes
really easy to screw the commit history up.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: OFBiz contributions & Github Pull Requests
Posted by Michael Brohl <mi...@ecomify.de>.
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 <mi...@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
>>>>
>>>
Re: OFBiz contributions & Github Pull Requests
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <mi...@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
>>>
>>
Re: OFBiz contributions & Github Pull Requests
Posted by Jacques Le Roux <ja...@les7arts.com>.
From y experience, if we want to be easy, pull/3 is good others are not.
But please, let's wait investigating Github PR templates before discussing this further
Jacques
Le 30/01/2020 à 16:35, Pierre Smits a écrit :
> I inadvertently posted wrong links.
>
>
> 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).
>
> This should be:
> 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/3).
>
>
> and
>
>
> The question is whether a commit message like in
> https://github.com/apache/ofbiz-plugins/pull/1 would be rejected.
>
> should be:
> The question is whether a commit message like in
> https://github.com/apache/ofbiz-plugins/pull/2 would be rejected.
>
>
> 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 4:04 PM Pierre Smits <pi...@apache.org> wrote:
>
>> 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 <mi...@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
>>>>
>>>
Re: OFBiz contributions & Github Pull Requests
Posted by Pierre Smits <pi...@apache.org>.
I inadvertently posted wrong links.
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).
This should be:
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/3).
and
The question is whether a commit message like in
https://github.com/apache/ofbiz-plugins/pull/1 would be rejected.
should be:
The question is whether a commit message like in
https://github.com/apache/ofbiz-plugins/pull/2 would be rejected.
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 4:04 PM Pierre Smits <pi...@apache.org> wrote:
> 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 <mi...@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
>> >
>>
>>
Re: OFBiz contributions & Github Pull Requests
Posted by Pierre Smits <pi...@apache.org>.
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 <mi...@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
> >
>
>
Re: OFBiz contributions & Github Pull Requests
Posted by Michael Brohl <mi...@ecomify.de>.
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
>