Hi all,
the vote passes with:
- 4 binding votes: Colin, Chris, Greg and myself
- 1 non-binding vote: Anton
Thanks everyone for the discussion and feedback!
Best,
On Mon, Jan 8, 2024 at 11:08 PM Colin McCabe wrote:
> Hi Chris,
>
> Based on some of the offline discussions we had, people
Hi Chris,
Based on some of the offline discussions we had, people generally feel that
major/minor releases have a large enough overhead that they don't want them
more frequently than every 4 months. (Obviously dot releases are a different
story) So Josep and I didn't want to raise the issue
Hi Colin,
The idea isn't to hold up 4.0.0 any longer; in fact, it's the opposite. If
things slip a bit with 3.8.0 and we take, for example, an extra month to
deliver it (or even to cut the branch), I don't think this should
necessarily translate to an extra month of latency between now and 4.0.0,
On Mon, Jan 8, 2024, at 09:05, Chris Egerton wrote:
> Hi Josep,
>
> Thanks for the KIP! +1 (binding).
>
> One small nit: I don't think we necessarily have to hold ourselves to
> releasing 4.0.0 "3 to 4 months after 3.8 branch is created" (quoting the
> timeline section of the KIP). IMO it's fine
Thanks for the changes. +1 (binding)
best,
Colin
On Sun, Jan 7, 2024, at 23:43, Josep Prat wrote:
> Hi all,
>
> Thanks for your comments,
> I reworded some parts of the KIP to express that:
> - The KIP is to agree that we need at least one more minor version in the
> 3.x series
> - Explicitly
Hi Josep,
Thanks for the KIP! +1 (binding).
One small nit: I don't think we necessarily have to hold ourselves to
releasing 4.0.0 "3 to 4 months after 3.8 branch is created" (quoting the
timeline section of the KIP). IMO it's fine to leave some wiggle room for
the 4.0.0 release without codifying
Thanks Josep for leading the KIP and building consensus on 3.8!
+1 (binding)
Greg
On Sun, Jan 7, 2024 at 11:45 PM Josep Prat wrote:
>
> Hi all,
>
> Thanks for your comments,
> I reworded some parts of the KIP to express that:
> - The KIP is to agree that we need at least one more minor version
Hi all,
Thanks for your comments,
I reworded some parts of the KIP to express that:
- The KIP is to agree that we need at least one more minor version in the
3.x series
- Explicitly saying that the list of KIPs is not exhaustive and that if
some are not done, we would need another minor version
-
I agree with Colin. Also, 4.0 would be started after 3.8 is branched (not
after 3.8.0 is released). The rest looks good.
Thanks!
Ismael
On Fri, Jan 5, 2024 at 11:27 PM Colin McCabe wrote:
> Hi,
>
> Thanks for calling the vote, Josep.
>
> I re-checked this, and saw something that we missed
Gathering up some other feedback from the DISCUSS thread:
- Please explicitly say that if we can't get the required features in in time,
we'll have another 3.x release, following the usual time-based schedule
- Please explicitly say that there may be other new features in 3.8 besides the
Hi,
Thanks for calling the vote, Josep.
I re-checked this, and saw something that we missed updating. One thing we
talked about earlier is that KIP-966 is actually not required for 3.8. What is
required is some way of enabling unclean leader election by default in KRaft.
(Which could be
+1 from me.
Den fre 5 jan. 2024 kl 10:33 skrev Josep Prat :
> Hi all,
>
> I'd like to start a vote on KIP-1012:
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1012%3A+The+need+for+a+Kafka+3.8.x+release
>
> Discussion thread is here:
>
Hi all,
I'd like to start a vote on KIP-1012:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1012%3A+The+need+for+a+Kafka+3.8.x+release
Discussion thread is here:
https://lists.apache.org/thread/kvdp2gmq5gd9txkvxh5vk3z2n55b04s5
Thanks!
---
Josep Prat
Open Source Engineering Director,
13 matches
Mail list logo
