Responding one of my questions: This is how I was able now to link tickets: >From the Jira ticket: More -> Link
Somehow I was expecting to see that option during ticket creation but it's available after the creation of the sub task. [image: image.png] El jue., 29 nov. 2018 a las 16:48, César Hernández Mendoza (< [email protected]>) escribió: > Hi, list: > > Contributing by example: this is how my PR for the MP rest client example > looks like: > https://github.com/apache/tomee/pull/210 > > However, this PR is not ready to be a merge, why? Well, the ticket > reference from the PR has the context: > https://issues.apache.org/jira/browse/TOMEE-2297 > > @Jonathan > Notice that even if both the PR and the commit has the reference to JIRA > ticket, no automatic reference generated in the Ticket. > I ended up adding a reference to the PR in the ticket as a comment. > I also couldn't create a "Depends on" between TOMEE-2298 and TOMEE-2297 in > the Jira fields. > > > > El mié., 28 nov. 2018 a las 16:09, Bruno Baptista (<[email protected]>) > escribió: > >> +1 on: >> >> "Something like: >> TOME-1234 - Commit foo >> TOME-1234 - Commit bla >> TOME-1234 - Commit xpto >> TOME-1234 - Commit aloha" >> >> Bruno Baptista >> https://twitter.com/brunobat_ >> >> >> On 28/11/18 18:54, Daniel Cunha wrote: >> > 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. >> >> >> > >> > > > -- > Atentamente: > César Hernández Mendoza. > -- Atentamente: César Hernández Mendoza.
