Hi Cesar, that's exactly what I like, we can push 1 commit per ticket. I like to use this way when PullRequest is not our normal way to work, just because to track it later to revert (for some reason) will be better than a revert lot of commits. :)
It is really hard to track when you have a lot of people working in a project and for each tickets we have a lot of commits, the commits will not be together and then it will be a nightmare to revert one change (all commits), because on change can have a lot of commits for different days. So, +1 to follow something like you had shared. Or we will need to mark for each comimt which it is related with the ticket. Something like: TOME-1234 - Commit foo TOME-1234 - Commit bla TOME-1234 - Commit xpto TOME-1234 - Commit aloha .... It maybe can help us to revert all change for ticket TOME-1234 with git-grep :) My thought. :) Em qua, 28 de nov de 2018 às 14:18, César Hernández Mendoza < [email protected]> escreveu: > > > > 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. > -- Daniel "soro" Cunha https://twitter.com/dvlc_
