Hi Josep, Thanks for the KIP.
>From a user's point of view, I don't see what the difference is between level >1 and level 2. Both are not completed, not API stable, not able to be used in >production, not enabled by default. The release manager's view is similar to >the user's point of view in this regard: those two levels are really the same. I also don't see what the difference is from a developer's point of view. In both cases, the feature is under development. It seems that we are trying to draw a distinction between the feature being started, and the feature not being started. But this is often vague in practice. People may start refactoring things prior to working on a feature, in preparation for that feature. Does that count as "starting the feature"? Your rejected alternatives section explains why you don't like "early availability" and "general availability." But it doesn't explain why you don't like the "preview" or "production" labels, which we have sometimes used in the past. > Using "alpha", "beta" and "gamma" has been rejected because of the widespread > use and > understanding of what "alpha" and "beta" mean in software development. I assume this was intended to say "misunderstanding"? Because rejecting a label because it's well-understood by our users seems... odd. :) If we get rid of the level 1 (which doesn't seem useful to me, as I've explained above), having "alpha", "beta", and "production" seems very easy to understand and friendly for our users. (Or, if you really absolutely need to have level 1, you could rename it to "not implemented" which seems an apt description?) best, Colin On Mon, Aug 19, 2024, at 03:35, Josep Prat wrote: > Hi TengYao, > > I get your point. I think smaller features definitely go too quickly > through stages to even acknowledge the change. > However, I would still think it's necessary to have these 2 levels > separated when it comes to bigger feature initiatives. The biggest use case > I see right now is to signal to the release manager (and the community) if > a feature is usable or not yet usable. I believe the fact to become usable > for a feature is a big enough step to gain its own entity. > > > Let's take KIP-853 as an example. This KIP was approved and initially added > to the release plan for Kafka 3.8. At this point the feature would be in > Level 1. By the time of the feature freeze the feature was still on Level > 1, so the release manager (who happened to be me) knew that the KIP would > not make it in this release and would need to be postponed to a future > release. After that, development on this feature continued and it was > declared to enter level 2 right in time for being in Kafka 3.9. > > Let me know what you think. > > Best, > > On Mon, Aug 19, 2024 at 8:51 AM TengYao Chi <kiting...@gmail.com> wrote: > >> Hello Josep, >> I think this KIP is a great addition to the community that we now have a >> crystal-clear definition for the state of a feature. >> >> In the current proposal, I think Level 1 is defined as the stage where a >> feature is "incomplete and unusable", while Level 2 represents a feature >> that is "usable but potentially incomplete". >> The distinction between these two levels might not always be clear, >> especially during the transition of a feature from "unusable" to "usable >> but incomplete". >> >> IMHO, to simplify the process and reduce confusion for both developers and >> users, I would suggest merging Level 1 and Level 2 into a single unified >> level. >> This merged level could cover the entire phase from when a feature is >> unstable to when it becomes usable but incomplete. >> >> WYDT? >> >> Best regards, >> TengYao >> >> Josep Prat <josep.p...@aiven.io.invalid> 於 2024年8月19日 週一 上午2:58寫道： >> >> > Hi Chia-Ping, >> > >> > As far as I can tell, Tiered Storage is still at level 3. I think the >> > intention would be to declare it level 4 in 4.0.0. >> > KIP-848 was in level 2 in Kafka 3.7. and it went level 3 in Kafka 3.8. >> > Level 4 features would be for example MirrorMaker2 for example. As far >> as I >> > understand the Docker image is level 4. >> > >> > Does that make sense? If so I can update the KIP with those examples. >> > >> > Best, >> > >> > ------------------ >> > Josep Prat >> > Open Source Engineering Director, Aiven >> > josep.p...@aiven.io | +491715557497 | aiven.io >> > Aiven Deutschland GmbH >> > Alexanderufer 3-7, 10117 Berlin >> > Geschäftsführer: Oskari Saarenmaa, Hannu Valtonen, >> > Anna Richardson, Kenneth Chen >> > Amtsgericht Charlottenburg, HRB 209739 B >> > >> > On Sun, Aug 18, 2024, 21:46 Chia-Ping Tsai <chia7...@gmail.com> wrote: >> > >> > > hi Josep >> > > >> > > Although I didn't join the discussion before, the KIP is interesting >> and >> > > great to me. >> > > >> > > one small comment: >> > > >> > > Could you please add existent features as an example to each level for >> > the >> > > readers who have poor reading (like me) ? For instance, I guess the new >> > > coordinator is level 3? tiered storage is level 4? >> > > >> > > Best, >> > > Chia-Ping >> > > >> > > >> > > >> > > Josep Prat <josep.p...@aiven.io.invalid> 於 2024年8月19日 週一 上午2:13寫道： >> > > >> > > > Hi all, >> > > > I want to start a discussion for KIP-1081: Graduation Steps for >> > Features. >> > > > >> > > > >> > > >> > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1081%3A+Graduation+Steps+for+Features >> > > > >> > > > We already had a bit of a discussion here >> > > > https://lists.apache.org/thread/5z6rxvs9m0bro5ssmtg8qcgdk40882bz and >> > > that >> > > > materialized into this KIP. >> > > > >> > > > I deliberately defined the graduation steps without giving them a >> name, >> > > so >> > > > we don't go bike-shedding there. There is a separate section for the >> > > names >> > > > of each step. Also an alternative set of names. I'd like to get some >> > > > feedback on the steps, and also on the names for the steps. >> > > > >> > > > Looking forward to your opinions, and hopefully only a tiny bit of >> > > > bike-shedding :) >> > > > >> > > > Best, >> > > > >> > > > -- >> > > > [image: Aiven] <https://www.aiven.io> >> > > > >> > > > *Josep Prat* >> > > > Open Source Engineering Director, *Aiven* >> > > > josep.p...@aiven.io | +491715557497 >> > > > aiven.io <https://www.aiven.io> | < >> > > https://www.facebook.com/aivencloud >> > > > > >> > > > <https://www.linkedin.com/company/aiven/> < >> > > > https://twitter.com/aiven_io> >> > > > *Aiven Deutschland GmbH* >> > > > Alexanderufer 3-7, 10117 Berlin >> > > > Geschäftsführer: Oskari Saarenmaa, Hannu Valtonen, >> > > > Anna Richardson, Kenneth Chen >> > > > Amtsgericht Charlottenburg, HRB 209739 B >> > > > >> > > >> > >> > > > -- > [image: Aiven] <https://www.aiven.io> > > *Josep Prat* > Open Source Engineering Director, *Aiven* > josep.p...@aiven.io | +491715557497 > aiven.io <https://www.aiven.io> | <https://www.facebook.com/aivencloud> > <https://www.linkedin.com/company/aiven/> <https://twitter.com/aiven_io> > *Aiven Deutschland GmbH* > Alexanderufer 3-7, 10117 Berlin > Geschäftsführer: Oskari Saarenmaa, Hannu Valtonen, > Anna Richardson, Kenneth Chen > Amtsgericht Charlottenburg, HRB 209739 B
