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.
