+1 as well. I don't think it's a big burden on the contributor to open a pull request and it makes things much easier for committers.
2017-02-08 14:33 GMT-05:00 Julian Hyde <[email protected]>: > 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 > >
