calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
Subject [DISCUSS] Patches
Date Wed, 08 Feb 2017 19:33:18 GMT
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


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