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