From personal experience, I think we should accept these small changes. I have had lots of cases where I am reading code or documentation on Github and found small errors or typos that are easy to fix, so I'd edit directly in Github and open a PR. These changes do improve the codebase and fix errors that could be misleading or confuse future maintainers and users.

It might be easy to say that we want to combine all these small changes into a bigger change, but most of the time, the author of the fix would have moved on and have forgotten about it, resulting in the improvement falling through the cracks. It also makes the amount of effort required to start contributing to the project a bit higher.

With Github integration, trivial fixes like this should be easy to merge with a click of a button and a quick glance at the diff on Github is usually sufficient for review.

I agree with Michael's suggestion that a JIRA should not be created for cases like this. They are also low-hanging fruit to improve the code-base and not accepting them seems like a missed opportunity to me.

Francis

On 26/09/2019 10:46 am, Michael Mior wrote:
I have mixed feelings about this, because on one hand, I'd like to
have these things corrected but on the other hand, we're already
bogged down with PRs. Perhaps a good compromise is to make it clear
that a JIRA should not be created and have some type of tag indicated
in the title of the PR. This might be a good time to create a pull
request template for GitHub that explains some of the policies (e.g.
making sure that non-trivial changes DO have a JIRA case).
--
Michael Mior
mm...@apache.org

Le mer. 25 sept. 2019 à 20:42, Julian Hyde <jh...@apache.org> a écrit :

I noticed this exchange in https://github.com/apache/calcite/pull/1475: 
<https://github.com/apache/calcite/pull/1475:>


Q. Just curious, does Calcite accept hotfix style PR that fixes typos, 
comments, etc.?

A. As long as they are large enough. But for 1 line typo fix, it is not worth a 
specific patch, we prefer to accumulate them together.

This is indeed our current position. And the reason we have given is that it 
takes considerable effort to review and commit a pull request, even a small one.

Should we reconsider this position?

Julian

Reply via email to