calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Mior <>
Subject Re: [DISCUSS] Patches
Date Wed, 08 Feb 2017 19:53:57 GMT
+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 <>:

> Our current policy is that we accept patches attached to JIRA case and
> pull requests to <
>>. 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 <>.
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message