Surely "Document how to use KIP-853" ( https://issues.apache.org/jira/browse/KAFKA-17048) should be required for the release, or? Why bother with the KIP and the release if you don't tell the users how to use it?
Jakub On Thu, Aug 1, 2024 at 8:40 PM Colin McCabe <cmcc...@apache.org> wrote: > Hi Mickael, > > KAFKA-14094 is basically a long list of things that we might want to do at > some time in the future, that are related to KIP-853. They are certainly > not all required for Kafka 3.9. > > Sorry that this was confusing. In order to avoid confusion about this in > the future, I'll move the stuff that isn't going to make 3.9 to a separate > umbrella JIRA. > > The things we need are just the things Jose posted at the beginning of the > week. And of those, only 2 are pending right now: the command-line stuff > and the final part of UpdateVoter. We expect those by Monday, at which > point we'll be feature-complete on KIP-853. > > best, > Colin > > > On Thu, Aug 1, 2024, at 09:23, Mickael Maison wrote: > > Hi, > > > > Considering KIP-853 does not look like it's near completion (20 out of > > 49 tasks done in https://issues.apache.org/jira/browse/KAFKA-14094), > > I'm not sure I understand why we decided to cut the 3.9 branch this > > early. By waiting a bit longer we could have reduced the risks in case > > KIP-853 is further delayed. > > > > I thought we had agreed on a shorter release cycle for 3.9 in case > > KIP-853 was completed earlier than the regular release schedule. > > > > We are now again (like for 3.8) in a weird case. Other KIPs being > > completed now are going to miss 3.9 and will have to wait till 4.0. > > Also at the moment we still can't start any of the 4.0 work due to the > > uncertainties about KIP-853. > > > > Thanks, > > Mickael > > > > > > > > > > > > On Wed, Jul 31, 2024 at 10:55 PM Chris Egerton <chr...@aiven.io.invalid> > wrote: > >> > >> Hi Colin, > >> > >> Would it be alright if I cherry-picked > >> https://github.com/apache/kafka/pull/16678 onto 3.9? This isn't a > >> regression but it's a low-risk fix that I'd like to get into the next > >> release if possible. > >> > >> Cheers, > >> > >> Chris > >> > >> On Wed, Jul 31, 2024 at 12:29 AM Ismael Juma <m...@ismaeljuma.com> wrote: > >> > >> > I would recommend against large refactorings in trunk until the first > RC > >> > for 3.9 - that will reduce cherry-pick friction. Once we have the > first RC, > >> > subsequent changes to 3.9 should be limited in scope. > >> > > >> > Ismael > >> > > >> > On Tue, Jul 30, 2024 at 4:31 PM Colin McCabe <cmcc...@apache.org> > wrote: > >> > > >> > > Yeah, please go ahead. I know a lot of people are waiting for 4.0. > >> > > > >> > > best, > >> > > Colin > >> > > > >> > > > >> > > On Tue, Jul 30, 2024, at 16:05, Matthias J. Sax wrote: > >> > > > Thanks for clarifying Colin. So my assumptions were actually > correct. > >> > > > > >> > > > We have a lot of contributors waiting to pick-up 4.0 tickets, and > I'll > >> > > > go ahead a tell them that we are ready and they can start to pick > them > >> > > up. > >> > > > > >> > > > Thanks. > >> > > > > >> > > > > >> > > > -Matthias > >> > > > > >> > > > On 7/30/24 3:51 PM, Colin McCabe wrote: > >> > > >> Hi Chia-Ping Tsai, > >> > > >> > >> > > >> If you can get them done this week then I think we can merge > them in > >> > to > >> > > 3.9. If not, then let's wait until 4.0, please. > >> > > >> > >> > > >> best, > >> > > >> Colin > >> > > >> > >> > > >> > >> > > >> On Tue, Jul 30, 2024, at 09:07, Chia-Ping Tsai wrote: > >> > > >>> hi Colin, > >> > > >>> > >> > > >>> Could you please consider adding > >> > > >>> https://issues.apache.org/jira/browse/KAFKA-16666 to 3.9.0 > >> > > >>> > >> > > >>> The issue is used to deprecate the formatters in core module. > Also, > >> > it > >> > > >>> implements the replacements for them. > >> > > >>> > >> > > >>> In order to follow the deprecation rules, it would be nice to > have > >> > > >>> KAFKA-16666 in 3.9.0 > >> > > >>> > >> > > >>> If you agree to have them in 3.9.0, I will cherry-pick them into > >> > 3.9.0 > >> > > when > >> > > >>> they get merged to trunk. > >> > > >>> > >> > > >>> Best, > >> > > >>> Chia-Ping > >> > > >>> > >> > > >>> > >> > > >>> José Armando García Sancio <jsan...@confluent.io.invalid> 於 > >> > > 2024年7月30日 週二 > >> > > >>> 下午11:59寫道： > >> > > >>> > >> > > >>>> Thanks Colin. > >> > > >>>> > >> > > >>>> For KIP-853 (KRaft Controller Membership Changes), we still > have the > >> > > >>>> following features that are in progress. > >> > > >>>> > >> > > >>>> 1. UpdateVoter RPC and request handling > >> > > >>>> <https://issues.apache.org/jira/browse/KAFKA-16533> > >> > > >>>> 2. Storage tool changes for KIP-853 > >> > > >>>> <https://issues.apache.org/jira/browse/KAFKA-16518> > >> > > >>>> 3. kafka-metadata-quorum describe changes for KIP-853 > >> > > >>>> <https://issues.apache.org/jira/browse/KAFKA-16521> > >> > > >>>> 4. kafka-metadata-quorum add voter and remove voter changes > >> > > >>>> <https://issues.apache.org/jira/browse/KAFKA-16523> > >> > > >>>> 5. Sending UpdateVoter request and response handling > >> > > >>>> <https://issues.apache.org/jira/browse/KAFKA-16534> > >> > > >>>> > >> > > >>>> Can we cherry pick them to the release branch 3.9.0 when they > get > >> > > merged to > >> > > >>>> trunk? They have a small impact as they shouldn't affect the > rest of > >> > > Kafka > >> > > >>>> and only affect the kraft controller membership change > feature. I > >> > > expected > >> > > >>>> them to get merged to the trunk branch in the coming days. > >> > > >>>> > >> > > >>>> Thanks, > >> > > >>>> > >> > > >>>> On Mon, Jul 29, 2024 at 7:02 PM Colin McCabe < > cmcc...@apache.org> > >> > > wrote: > >> > > >>>> > >> > > >>>>> Hi Kafka developers and friends, > >> > > >>>>> > >> > > >>>>> As promised, we now have a release branch for the upcoming > 3.9.0 > >> > > release. > >> > > >>>>> Trunk has been bumped to 4.0.0-SNAPSHOT. > >> > > >>>>> > >> > > >>>>> I'll be going over the JIRAs to move every non-blocker from > this > >> > > release > >> > > >>>> to > >> > > >>>>> the next release. > >> > > >>>>> > >> > > >>>>> From this point, most changes should go to trunk. > >> > > >>>>> *Blockers (existing and new that we discover while testing the > >> > > release) > >> > > >>>>> will be double-committed. *Please discuss with your reviewer > >> > whether > >> > > your > >> > > >>>>> PR should go to trunk or to trunk+release so they can merge > >> > > accordingly. > >> > > >>>>> > >> > > >>>>> *Please help us test the release! * > >> > > >>>>> > >> > > >>>>> best, > >> > > >>>>> Colin > >> > > >>>>> > >> > > >>>> > >> > > >>>> > >> > > >>>> -- > >> > > >>>> -José > >> > > >>>> > >> > > > >> > >
