And one more thing: patches do not (necessarily) contain an author name and email address. The committer needs to fill these out when committing the patch. So, more back and forth ensues.
Julian > 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 >
