Hi Chris, I don't see why this shouldn't go to 3.9. Would you call this a bugfix?
best, Colin On Wed, Jul 31, 2024, at 13:54, Chris Egerton 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é >> > >>>> >> > >>
