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 < [email protected]> 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 <[email protected]> > Sent: Friday, September 27, 2019 7:25:56 PM > To: [email protected] <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 > > > [email protected] > > > > > > Le jeu. 26 sept. 2019 à 07:28, TANG Wen-hui > > > <[email protected]> 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 > > >> > > >> > > >> > > >> [email protected] > > >> > > >> From: Haisheng Yuan > > >> Date: 2019-09-26 10:17 > > >> To: Francis Chuang; [email protected] ([email protected]) > > >> 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<[email protected]> > > >> 日 期：2019年09月26日 09:20:49 > > >> 收件人：<[email protected]> > > >> 主 题：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 > > >>> [email protected] > > >>> > > >>> Le mer. 25 sept. 2019 à 20:42, Julian Hyde <[email protected]> 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 ~~~~~~~~~~~~~~~~~~
