Thanks for the encouragement, Albert. I fight every day to get people to write commit messages that are clearer, more concise, and more meaningful to non-technical users. I can imagine that it is not too pleasant for each code contributor who is on the receiving end of my criticism. But I am glad that you appreciate the results.
I think it would be OK if we end up with a commit log that looks like this: * [CALCITE-3374] Error format check result for explain plan as json (Wang Yanlin) * Improve comment * [CALCITE-3363] JoinUnionTransposeRule.RIGHT_UNION should not match SEMI/ANTI Join (Jin Xing) * Fix a typo * [CALCITE-3323] Add mode to SqlValidator that treats statements as valid if they contain unknown functions (Ryan Fu) * [CALCITE-3370] In JDBC adapter for Microsoft SQL Server, emulate NULLS FIRST using CASE expression (Justin Swett) * [CALCITE-3369] In LatticeSuggester, recommend lattices based on UNION queries * Improve READMEs and release howto instructions * [CALCITE-3365] Don't require use of JdbcSchema in QuerySqlStatisticProvider (Lindsey Meyer) That’s the real commit log with two hypothetical commits "Improve comment” and "Fix a typo” added. "Improve READMEs and release howto instructions” is a real commit from Stamatis. The release manager would remove the two “small contributions”, resulting in the following release notes: Features: * [CALCITE-3323] Add mode to SqlValidator that treats statements as valid if they contain unknown functions (Ryan Fu) * [CALCITE-3369] In LatticeSuggester, recommend lattices based on UNION queries * [CALCITE-3365] Don't require use of JdbcSchema in QuerySqlStatisticProvider (Lindsey Meyer) Bug fixes: * [CALCITE-3374] Error format check result for explain plan as json (Wang Yanlin) * [CALCITE-3363] JoinUnionTransposeRule.RIGHT_UNION should not match SEMI/ANTI Join (Jin Xing) * [CALCITE-3370] In JDBC adapter for Microsoft SQL Server, emulate NULLS FIRST using CASE expression (Justin Swett) Site: * Improve READMEs and release howto instructions How does the release manager know that they are “small contributions”? Because their commit message describes the change, and it’s clear that they are not adding a feature, fixing a bug, or improving end-user documentation. Julian > On Sep 27, 2019, at 7:14 PM, Albert <zinki...@gmail.com> wrote: > > I really liked the compact commit log messages in calcite repo. > on the one hand contributions should be encouraged, on the other hand I > don't want to see commit log jammed with 'fix typo' stuff. let's hope that > won't be the case. > > On Sat, Sep 28, 2019 at 4:27 AM Julian Feinauer < > j.feina...@pragmaticminds.de> wrote: > >> Yes, I totally agree that's a major change by any means. As Julian pointed >> out above its only about non-code changes. >> >> Julian >> ________________________________ >> From: Andrei Sereda <and...@sereda.cc> >> Sent: Friday, September 27, 2019 7:25:56 PM >> To: dev@calcite.apache.org <dev@calcite.apache.org> >> Subject: Re: [DISCUSS] Small contributions >> >> I presume 3rd party library upgrades should go through regular process >> (jira/PR etc.) ? >> >> Dependency upgrade is not considered "small change" since impact is >> greater than just a "typo fix". >> >> >> On Thu, Sep 26, 2019 at 1:47 PM Julian Hyde <jh...@apache.org> wrote: >> >>> A few points. >>> >>> I don’t like the term “hot fix”. A hot fix has an existing meaning[1] - >> it >>> is a patch you apply to your binaries. Let’s not use that term. >>> >>> Let’s define “small contributions” as contributions that do not modify >>> code and therefore will not break anything, do not need a test or >>> documentation change, and do not need a CI run. >>> >>> I am in favor of accepting small contributions. I wasn’t previously. >>> >>> We can have guidelines about how to label these small contributions (e.g. >>> git labels, certain words in the commit message or PR description). But >> we >>> shouldn’t expect or require contributors to follow those guidelines. By >>> their nature, these contributors have not had time to read all of our >>> policy documents. >>> >>> Reviewers must know what our policy is, and should massage commit >> messages >>> tot conform to policy. >>> >>> These kinds of changes are, by definition, very small and simple. A >>> committer can review, approve, fix up, and push to master, and close the >> PR >>> in one go. Five minutes. If the PR requires a back-and-forth then it is >> not >>> a “simple” change. >>> >>> We should not require a JIRA case. >>> >>> We not apply the usual policy of appending the contributor’s name to the >>> commit message. A typical commit message would be “Fix a comment”. >>> >>> Release manager should remove these kinds of trivial changes from the >>> release notes. They add nothing to the release notes. >>> >>> These kinds of changes do earn “merit” - the basis on which we make >> people >>> committers - but they earn less merit than a bug fix, a new feature, a >>> detailed response to a question on the dev list, or a conference talk. I >>> don’t want people to believe that they can earn committership by fixing >> 100 >>> typos. >>> >>> There can be problems if a community over-relies on small PRs. In >>> particular, there is a project in the Incubator that has only one or two >>> regular developers but receives hundreds of contributions a few lines >> long >>> via PRs. The discussion occurs in the PRs, and contributors rarely make >>> more than 1 or 2 contributions. The problem for the project is that there >>> is no emergent “community”. This is a serious problem for that project, >> and >>> obviously we do not have that problem. Still, there is a side effect to >> the >>> back-and-forth discussion to get a change accepted, namely that the >>> individuals get to know each other. We don’t want to lose that. >>> >>> >>> Julian >>> >>> [1] https://en.wikipedia.org/wiki/Hotfix < >>> https://en.wikipedia.org/wiki/Hotfix> >>> >>> >>> >>> >>>> On Sep 26, 2019, at 5:17 AM, Michael Mior <mm...@apache.org> wrote: >>>> >>>> I thought about a label, but I think it's probably more productive to >>>> just review the change immediately if it really is something trivial. >>>> The problem is that labels can only be applied by committers. That's >>>> why I suggested asking those who submit PRs to include something in >>>> the PR title. If others think a label would help though, I'm not >>>> opposed to it. >>>> -- >>>> Michael Mior >>>> mm...@apache.org >>>> >>>> Le jeu. 26 sept. 2019 à 07:28, TANG Wen-hui >>>> <winifred.wenhui.t...@gmail.com> a écrit : >>>>> >>>>> I agree that we should accept these small changes but not create JIRA >>> for them. >>>>> In my opinion, maybe we can label the PR of these small changes. And >>> process them at regular intervals in case of forgetting. >>>>> >>>>> best, >>>>> -- >>>>> wenhui >>>>> >>>>> >>>>> >>>>> winifred.wenhui.t...@gmail.com >>>>> >>>>> From: Haisheng Yuan >>>>> Date: 2019-09-26 10:17 >>>>> To: Francis Chuang; dev@calcite.apache.org (dev@calcite.apache.org) >>>>> Subject: Re: Re: [DISCUSS] Small contributions >>>>>> 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. >>>>> >>>>> Make sense. I think our current position worth reconsidering and I >>>>> agree with Francis. >>>>> >>>>> - Haisheng >>>>> >>>>> ------------------------------------------------------------------ >>>>> 发件人：Francis Chuang<francischu...@apache.org> >>>>> 日 期：2019年09月26日 09:20:49 >>>>> 收件人：<dev@calcite.apache.org> >>>>> 主 题：Re: [DISCUSS] Small contributions >>>>> >>>>> 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 >>> >>> >> > > > -- > ~~~~~~~~~~~~~~~ > no mistakes > ~~~~~~~~~~~~~~~~~~
