Hi Colin, Thanks for your feedback! > 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"?
The main difference between level 1 and level 2 is the fact that only when a feature reaches level 2 it makes sense to ask for early adopters to start tinkering with it. For example, KIP-853 would have been at level 1 during Kafka 3.8.0. It was not complete and not usable at all. Once Kafka 3.9.0 is out, KIP-853 would reach level 2. The feature is mostly finished ( https://issues.apache.org/jira/browse/KAFKA-14094 is done), but there some (minor) functionalities still missing ( https://issues.apache.org/jira/browse/KAFKA-17241 at the moment of writing 22 subtasks are open). The feature is now usable, but maybe some aspects are not 100% polished. We would expect users to start playing around with it (maybe not jumping to production just right yet, but start testing). Regarding the name, I specifically didn't want to go with alpha - beta, because this is usually used for software releases or products. Applying it to features might, in my opinion, cause confusion on the state of our Kafka releases. I know we don't use the concept of alpha and beta, but rather release candidate, but as these words are so embroidered in software versioning I would try to exclude them. Best, On Fri, Aug 23, 2024 at 7:01 PM Colin McCabe <cmcc...@apache.org> wrote: > 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 > -- [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
