Thanks for the input Matthias, I guess we will keep things as they are to prevent yet another layer added on top. Eric has already taken the next available number and it's recorded on the wiki so I suppose there's no additional work required here.
Regards, -Matt -----Original Message----- From: Matthias J. Sax <mj...@apache.org> Sent: Friday, June 14, 2024 3:35 PM To: dev@kafka.apache.org Subject: Re: [QUESTION] What to do about conflicted KIP numbers? I don't think that there is an official guideline. Personally, I would suggest that the corresponding KIP owners agree who is keeping the conflicting number, and how is changing it. For the ones changing the number, I would propose to restart a new DISCUSS thread using the new number to separate the KIP threads. Not sure if the is a better way to handle this... Just an idea on how I would do it. Not sure if we can improve the wiki instruction to make the race condition less likely? Seems, this would happen if two people look at the next KIP number let's say X, but don't bump it right way to X+1 and publish their KIP with X a few hours/days later without verifying that X is still next available KIP number? -Matthias On 6/14/24 3:10 PM, Welch, Matt wrote: > Hi Kafka devs, > > I submitted a KIP last week and encountered a KIP-process race condition > where my KIP number was consumed by another dev without updating the wiki > page containing KIPs: Kafka Improvement Proposals - Apache Kafka - Apache > Software > Foundation<https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals> > > There are now least three separate dev-list threads referencing this > conflicted KIP number so I'm concerned that discussion around this number > will now be permanently confusing due to the conflict and multiple concurrent > unrelated threads referencing the same KIP number. I've intentionally kept > the KIP numbers out of this email to prevent yet another thread referencing > them. > > While I'm happy to keep going with my existing KIP number, I was wondering if > I should "abandon" it and create a new one. > This solution seems like it could create extra confusion, however, so what is > the best course of action here? > > Thanks, > Matt >
