I'd be against squashing commits, as it hides who the real author is. If
you work hard on something, and I merge it in, squashing your commits in
the process, it looks like I authored it and not you. When commits are
not
squashed, you can see you authored it, and I reviewed and merged. When it
comes to proposing and voting in new committers, being able to see their
contributions is very helpful. Hope that makes sense.
The squash scenario to describe is at the end of the workflow and your
observation is valid.
My squash recommendation is at the beginning of the workflow when the
contributor finished his work on his local repo.
Check for instance step 10 from this git workflow:
https://github.com/forge/core/blob/master/CONTRIBUTING.asciidoc#git-workflow
El mié., 28 nov. 2018 a las 9:49, Jonathan Gallimore (<
[email protected]>) escribió:
Hey Cesar
Some specific feedback inline. The short version is the project is
technically CTR (commit then review). As a group, we've enjoyed using PRs
for discussion, but we have discussed moving to RTC (review then commit)
a
couple of times, and voted against it each time. Currently the ASF Git
repository is the single source of truth for our code. That could
possibly
change, but I don't think straight-up GitHub is an option.
On Wed, Nov 28, 2018 at 3:08 PM César Hernández Mendoza <
[email protected]> wrote:
Thanks, Jonathan for the reply.
PRs aren't actually required, committers can commit directly and
contributors can send in patches on JIRAs.
My two cents is that by having the flexibility of doing just a patch
and
direct commits, then the PR and JIRA are not enforced and that leads to
interesting commit history that is hard to track when you are
troubleshooting or doing git bisects.
Ultimately we all ended up working with Github and we don't interact
directly with the mirror process.
There's a variety of code hosting options at ASF, including ASF hosted
SVN
and Git. GitBox is also available, I believe. I don't think GitHub itself
is an option, and hence why its a readonly mirror with the ASF Git
repository as the single source of truth.
If one goes now to https://github.com/apache/tomee/commits/master and
click
on one random commit, there is no tracking about the context of the
commit
since there is no reference to Jira and also commits (merges) are not
atomic and that lead to a fix been spread in various commits in time.
I think asking if people can prefix the commit message with the JIRA ID
is
a simple standard that could work.
I know this raised the barrier for someone doing Open Source
contribution
because we would be enforcing the creation of a JIRA
I think requiring a JIRA is reasonable, and is generally what we do.
, require the
contributor to squash his/her commits before creating the PR and adding
the
convention TOMEE-XXXX for PR subject. But at the end, I think we would
have
more clean Github branches even if then Apache bots take over the code
periodically to integrate the code into Apache infrastructure.
I'd be against squashing commits, as it hides who the real author is. If
you work hard on something, and I merge it in, squashing your commits in
the process, it looks like I authored it and not you. When commits are
not
squashed, you can see you authored it, and I reviewed and merged. When it
comes to proposing and voting in new committers, being able to see their
contributions is very helpful. Hope that makes sense.
Cheers
Jon
El mié., 28 nov. 2018 a las 1:37, Jonathan Gallimore (<
[email protected]>) escribió:
I don't know if its specifically what you're after, but there is an
element
of integration. If you specify the TOMEE-XXXX reference on the
subject
of
your PR you'll see the JIRA ticket gets updates from the PR.
Github, while popular, isn't the actual git repository at the ASF
for
TomEE - it's a read only mirror.
PRs aren't actually required, committers can commit directly and
contributors can send in patches on JIRAs.
Those might be constraints in terms of what you're looking for.
Following a
standard of including the JIRA ID on commits or PRs makes sense. Feel
free
to make other suggestions that might help too though. I recall
writing
SVN
revisions in Jiras a long time back.
Jon
On Wed, 28 Nov 2018, 03:49 César Hernández Mendoza <
[email protected]
wrote:
Hi team,
Is there any restriction that prevents Apache Jira ticket to have
the
reference to the Github PullRequest(s) that were already merged?
So far I have found cumbersome to find a ticket in Jira and then go
into
git logs to hunt all the commits related to that Jira ticket.
In the best case scenario, the commits have the Jira ticket number,
but
that is not always the case.
--
Atentamente:
César Hernández Mendoza.
--
Atentamente:
César Hernández Mendoza.
--
Atentamente:
César Hernández Mendoza.
