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