We should be very clear on what users can rely on when it comes to the docker images (i.e. what are public interfaces) and what are implementation details (and can be changed whenever we want). That's the only way to have a maintainable system. Same way we make changes to internal classes even though users can (and some do) rely on them.
Ismael On Wed, Dec 20, 2023 at 10:55 AM Mickael Maison <mickael.mai...@gmail.com> wrote: > Hi, > > Yes changes have to be merged by a committer but for this kind of > decisions it's best if it's seen by more than one. > > > Hmm, is this a blocker? I don't see why. It would be nice to include it > in 3.7 and we have time, so I'm fine with that. > Sure, it's not a blocker in the usual sense. But if we ship this Go > binary it's possible users extending our images will start depending > on it. Since we want to get rid of it, I'd prefer if we never shipped > it. > > Thanks, > Mickael > > > On Wed, Dec 20, 2023 at 4:28 PM Ismael Juma <m...@ismaeljuma.com> wrote: > > > > Hi Mickael, > > > > A couple of comments inline. > > > > On Wed, Dec 20, 2023 at 3:34 AM Mickael Maison <mickael.mai...@gmail.com > > > > wrote: > > > > > When you say, "we have opted to take a different approach", who is > > > "we"? I think this decision should be made by the committers. > > > > > > > Changes can only be merged by committers, so I think it's implicit that > at > > least one committer would have to agree. :) I think Vedarth was simply > > saying that the group working on the KIP had a new proposal that > addressed > > all the goals in a better way than the original proposal. > > > > I marked the Jira (https://issues.apache.org/jira/browse/KAFKA-16016) > > > as a blocker for 3.7 as I think we need to make this decision before > > > releasing the docker images. > > > > > > > Hmm, is this a blocker? I don't see why. It would be nice to include it > in > > 3.7 and we have time, so I'm fine with that. > > > > Ismael >
