calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <>
Subject Re: [DISCUSS] Patches
Date Wed, 08 Feb 2017 23:07:25 GMT
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


> On Feb 8, 2017, at 2:56 PM, Alan Gates <> 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 <> 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 <> 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 <> wrote:
>>>> 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
>>>> 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

View raw message