I agree with you that JIRA is better at managing back-ports than git is. In my view, non-trivial commits — anything that fixes a user bug or feature — should have a JIRA case. Calcite seems to follow this policy — about 95% of commits have a corresponding JIRA case. The remainder are usually for cosmetic code changes, documentation and web site changes.
Julian > On Feb 8, 2017, at 2:56 PM, Alan Gates <[email protected]> wrote: > > I agree PRs are easy to work with for developers. Here's the same question I > was trying to ask put a different way: > > If a user discovers that feature X is broken, how easy it for him to find out > whether someone before him has found this bug and then figure out what > version of the software he needs to fix it. Bug tracking systems are > optimized for answering these queries, and I don't think source control > systems are. > > Maybe calcite is enough developer focussed that anyone searching for issues > will be comfortable skimming through the git log to figure it out, so maybe > my concerns are moot in this case. > > Alan. > >> On Feb 8, 2017, at 12:30 PM, Julian Hyde <[email protected]> wrote: >> >> In principle it is hard to compute the delta of a pull request, but in >> practice it is easy. A well-formed pull request is a branch that is a small >> number of commits away from the master branch at the time, and the pull >> requests that we tend to accept are well-formed. >> >> Since we don’t rewrite the master branch, you can easily apply the pull >> request using “git rebase”. Because git knows where where the pull request’s >> branch meets the master branch, it can do a better job than “patch” could. >> >> Julian >> >> >>> On Feb 8, 2017, at 12:21 PM, Alan Gates <[email protected]> wrote: >>> >>> I agree that PRs are easier to manage than attaching patches to JIRA. And >>> now days most contributors seem to prefer them as well. >>> >>> One question I have is about traceability and findability. It is very nice >>> for people to be able to come to JIRA and figure out if others have had the >>> same problem they have, and if so if and where it's fixed, and exactly >>> which commits they need to pick up if they want the fix. Can all this be >>> achieved with just PRs? >>> >>> If the answer is that PRs can't achieve that, I'd still vote for moving to >>> them. But I would also suggest continuing to open JIRAs that point to the >>> PRs. >>> >>> Alan. >>> >>>> On Feb 8, 2017, at 11:33 AM, Julian Hyde <[email protected]> wrote: >>>> >>>> Our current policy is that we accept patches attached to JIRA case and >>>> pull requests to https://github.com/apache/calcite >>>> <https://github.com/apache/calcite>. I would like to propose that we no >>>> longer support patches. >>>> >>>> Why? I argue that it makes the process easier for the committer. The pull >>>> request implicitly does “git add” and “git remove”, whereas when applying >>>> a patch you have to remember to apply these. The pull request comes in a >>>> branch, so if I modify the code as I am reviewing it, I can easily save >>>> and restore my state. Also, a pull request is “valid” as a contribution, >>>> from an IP standpoint, even when not accompanied by a JIRA case. >>>> >>>> Recently I went through 5 rounds of patches for a particular feature. I >>>> couldn’t tell what had changed between one iteration of the patch and the >>>> next (you can’t “diff" patches - you need to apply the patches to separate >>>> git branches and diff the branches - yuck!). And I went through 3 test >>>> cycles and 24 hours before I managed to “git add” all of the files. Yes, I >>>> did “git status” and I missed the 2 new files among all of the “.orig” and >>>> “.rej” files in my sandbox. >>>> >>>> In summary. I propose that we accept contributions only as pull requests >>>> to https://github.com/apache/calcite <https://github.com/apache/calcite>. >>>> If they are non-trivial they should be accompanied by a JIRA case. >>>> Committers can propose changes any way they like, as long as they commit >>>> the changes themselves, but if they want to make it easier for others to >>>> review, they should use either a personal git branch or a pull request. >>>> >>>> Julian >>>> >>> >> >
