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 < cesargu...@gmail.com> 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 (< > jonathan.gallim...@gmail.com>) 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 <cesargu...@gmail.com > > 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. >
