While the point about being less time is probably correct, yeah if
something is half-done, we should keep them in the master branch, and/or
don't expose it to the end users (which I believe we usually do).
Good thing is that we can make the schedule predictable. Suppose that the
branchcut date is p
Awesome!
On Thu, 16 Feb 2023 at 06:39, Dongjoon Hyun wrote:
> Great! Thank you, Liang-Chi!
>
> Dongjoon.
>
> On Wed, Feb 15, 2023 at 9:22 AM L. C. Hsieh wrote:
>
>> The vote passes with 12 +1s (4 binding +1s).
>> Thanks to all who helped with the release!
>>
>> (* = binding)
>> +1:
>> - Mridul
Great! Thank you, Liang-Chi!
Dongjoon.
On Wed, Feb 15, 2023 at 9:22 AM L. C. Hsieh wrote:
> The vote passes with 12 +1s (4 binding +1s).
> Thanks to all who helped with the release!
>
> (* = binding)
> +1:
> - Mridul Muralidharan (*)
> - Dongjoon Hyun (*)
> - Sean Owen (*)
> - Enrico Minack
> -
I don't think there is a delay per se, because there is no hard release
date to begin with, to delay with respect to. It's been driven by, "feels
like enough stuff has gone in" and "someone is willing to roll a release",
and that happens more like every 8-9 months. This would be a shift not only
in
Hi,
Sorry for a silly question, but do we know what exactly caused these
delays? Are these avoidable?
It is not a systematic observation, but my general impression is that we
rarely delay for sake of individual features, unless there is some soft
consensus about their importance. Arguably, t
The vote passes with 12 +1s (4 binding +1s).
Thanks to all who helped with the release!
(* = binding)
+1:
- Mridul Muralidharan (*)
- Dongjoon Hyun (*)
- Sean Owen (*)
- Enrico Minack
- Bjørn Jørgensen
- Yikun Jiang
- Yang Jie
- Yuming Wang
- John Zhuge
- William Hyun
- Chao Sun
- L. C. Hsieh (*)