It’s a difficult call. There’s kind of a time - functionality trade-off. At some point it’s diminishing returns - waiting another day won’t significantly improve the goodness of the release, and lots of devs are holding off risky changes because they don’t want to reduce the quality.
As RM, it’s your call. Bring down the hammer when you think it’s ready, and don’t be afraid to hurt people’s feelings. There will always be another release! Julian > On Jul 17, 2020, at 12:14 AM, Chunwei Lei <chunwei.l...@gmail.com> wrote: > > Julian, thank you for your kindly reminder. I am about to ask whether I > should hold the release or not. > > I don't want to see that we merge PR in a hurry just for catching up > with the release. So I left more time for that as long as the issue is > supposed to be fixed in the latest release(i.e. CALCITE-4034[1]). > > I will try to fix CALCITE-4118 today. If it takes longer than expected, I > will exclude it and start preparing the RC. > > [1] > https://lists.apache.org/thread.html/rb1b45a6bb06bceabed5be542134e9a894173a5130d73cff415ddcfdf%40%3Cdev.calcite.apache.org%3E > > Best, > Chunwei > > > On Fri, Jul 17, 2020 at 2:14 PM Julian Hyde <jh...@apache.org> wrote: > >> Chunwei, >> >> I think you said you'd have an RC in the middle of this week. In my >> opinion, you should hold to that. There will always be one or two last >> bugs that don't make it into a release. No matter - they'll be in the >> next one. >> >> For example, I've been trying to get the InnoDB adapter ( >> https://issues.apache.org/jira/browse/CALCITE-4034 ) in shape for >> 1.24. But it's taking longer than expected. So, don't hold the release >> for me. >> >> Julian >> >> On Thu, Jul 16, 2020 at 7:19 PM Chunwei Lei <chunwei.l...@gmail.com> >> wrote: >>> >>> Hi, Zoltan. Thank you for your reply. >>> >>> Regarding CALCITE-4118, I would like to try to fix it. >>> >>> >>> >>> Best, >>> Chunwei >>> >>> >>> On Thu, Jul 16, 2020 at 2:08 PM Zoltan Haindrich <k...@rxd.hu> wrote: >>> >>>> Hey Chunwei! >>>> >>>> about CALCITE-4118: I wanted to get back to it - but I was busy doing >>>> other things... >>>> The patch is not ready; it's wip branch is here: >>>> https://github.com/kgyrtkirk/calcite/tree/4118-cast-varbinary >>>> My plan was to figure out how to do it without writing down concreate >>>> types(like CHAR) in that check. >>>> >>>> Because we're going out for a long weekend - I may only get back to it >> on >>>> Tuesday or so...which might be too late for the release. So it would be >>>> probably the best if >>>> someone could take it over. >>>> >>>> cheers, >>>> Zoltan >>>> >>>> >>>> On 7/15/20 8:11 AM, Chunwei Lei wrote: >>>>> Thank you for all your effort. >>>>> >>>>> Now there're only two issues(CALCITE-4000[1] and CALCITE-4118[2]) to >>>>> be fixed in 1.24.0. >>>>> >>>>> As for CALCITE-4000, it needs a final review. Could you someone help >>>> review? >>>>> As for CALCITE-4118, I could not find the PR for it. Could someone >> some >>>>> point it out if I >>>>> missed it? >>>>> >>>>> >>>>> [1] https://issues.apache.org/jira/browse/CALCITE-4000 >>>>> [2] https://issues.apache.org/jira/browse/CALCITE-4118 >>>>> >>>>> Best, >>>>> Chunwei >>>>> >>>>> >>>>> On Fri, Jul 10, 2020 at 2:46 PM Chunwei Lei <chunwei.l...@gmail.com> >>>> wrote: >>>>> >>>>>> Rui, >>>>>> >>>>>>> Question: are you planning to follow the practice of the last >> release >>>>>> (i.e. >>>>>> lock master branch and clean up JIRA with fix version 1.24.0 marked >>>> before >>>>>> re-open master branch?) >>>>>> >>>>>> Yes, I think so. >>>>>> >>>>>> Best, >>>>>> Chunwei >>>>>> >>>>>> >>>>>> On Fri, Jul 10, 2020 at 2:43 AM Julian Hyde <jh...@apache.org> >> wrote: >>>>>> >>>>>>> We have 174 open PRs. Quite a few of these are high-quality and >> ready >>>>>>> to go in, and they are not from committers, so they don't stand a >>>>>>> chance unless a committer takes the time to look at them. New >>>>>>> contributors will become demoralized if they do good work and it is >>>>>>> never looked at. >>>>>>> >>>>>>> In the next 5 days, could every committer review one or two PRs, >> and >>>>>>> merge it to master if it is ready? You would be doing your part to >>>>>>> keep our community healthy and growing. >>>>>>> >>>>>>> Julian >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 9, 2020 at 11:26 AM Julian Hyde <jh...@apache.org> >> wrote: >>>>>>>> >>>>>>>> Chunwei, >>>>>>>> >>>>>>>> Thanks for kicking this off. RC on 7/14 sounds good. >>>>>>>> >>>>>>>> I have logged https://issues.apache.org/jira/browse/CALCITE-4117 >>>>>>>> ("Release Calcite 1.24.0") and assigned it to you. I have a >> couple of >>>>>>>> bugs that I want to make depend on it (i.e. they can only be fixed >>>>>>>> AFTER 1.24). >>>>>>>> >>>>>>>> On Wed, Jul 8, 2020 at 11:25 PM Chunwei Lei < >> chunwei.l...@gmail.com> >>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Approximately one and a half months have passed from the previous >>>>>>> release >>>>>>>>> (Calcite >>>>>>>>> 1.23.0) and I was thinking that it would be nice to have the next >>>>>>> release >>>>>>>>> around the 20 >>>>>>>>> of July, considering there are already ~70 commits and some >> commits >>>> of >>>>>>>>> pull#2024[1] >>>>>>>>> to be merged after 1.24 is large and easy to be broken. To do >> this I >>>>>>> think >>>>>>>>> we should try >>>>>>>>> to have an RC around the 14 of July. >>>>>>>>> >>>>>>>>> The progress towards the next release can be seen in [2]. As you >> can >>>>>>> see, >>>>>>>>> we have 10 >>>>>>>>> issues marked for fixing in 1.24.0. I suggest we focus on solving >>>>>>> these >>>>>>>>> issues in the >>>>>>>>> following days. Apart from these issues, if you really think >> other >>>>>>> issues >>>>>>>>> should be fixed >>>>>>>>> in 1.24.0, please comment in this thread and set the fix version >> to >>>>>>> 1.24.0. >>>>>>>>> >>>>>>>>> Don't hesitate to reply to this thread if the plan above is not >>>>>>> convenient >>>>>>>>> for you! >>>>>>>>> >>>>>>>>> [1] https://github.com/apache/calcite/pull/2024 >>>>>>>>> [2] >>>>>>>>> >>>>>>> >>>> >> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950 >>>>>>>>> >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Chunwei >>>>>>> >>>>>> >>>>> >>>> >>
