Hi David, DA2.1. Agreed
DA2.2. I agree with this, yes. This should be, in my opinion, KIP specific and part of the DISCUSS thread. DA4.2 I think it makes sense to have this requirement. We might need to word it properly, but I think it makes sense. DA7. Thanks for keeping the bikeshed painted :) Best, On Tue, Aug 27, 2024 at 4:55 PM David Arthur <david.art...@confluent.io.invalid> wrote: > DA2.1 re "big" and "simple" features. I think the process described in this > KIP should be for "big" features only, right? We don't want to add the > overhead of tracking the maturity/stability of a new metric or API field. > Conceptually, I understand that these would immediately be level 4 > features, but I think this should be implicit and not required by smaller > KIPs. > > DA2.2 This means we need some distinction for "big" features. What > qualifies? Maybe this is something we can decide in the discussion phase > for each KIP. > > DA3.1 ok > > DA4.1 Fair enough, we can raise a follow up KIP for backport policy. > > DA4.2 On the bugfixes, once something has reached level 4, we may want to > consider that Blocker/Critical bugs should trigger a patch release. After > all, if we say it's production ready and something turns out to be severely > broken, we should fix it promptly. That would be my expectation as a user. > This could be part of the follow up KIP > > DA5.1 Yea that's fine > > DA6.1 Ok, thanks I missed that section > > DA7. Regarding the names, "Preview" and "Early Access" are too ambiguous in > my opinion. Both convey a "before it's baked" status, but to me it's not > easy to distinguish between the two. I like the literary terms, but it > might be a bit too idiomatic. > > Here' my pick for the bikeshed color: > 2: Experimental > 3: Beta > 4. Stable (or Production) > > -David > > > > On Mon, Aug 26, 2024 at 1:51 PM Josep Prat <josep.p...@aiven.io.invalid> > wrote: > > > Hi Colin, > > > > Names are in the KIP. Level 1 to 4 are never meant to be used outside of > > this discussion. It's my, apparently successful, attempt to focus on what > > the levels mean instead of their names: > > > > > Names > > > > "In Development" > > "Early Access" > > "Preview" > > "Production Ready" > > > > Alternatively, if we want to be a bit more playful we could go with a > theme > > borrowed from the book industry (as an homage to Franz Kafka): > > > > "In Development" > > "Manuscript" > > "Pre-print" > > "Published" > > > > > > Regarding level 2, it is intended to be usable up to some extent. For > > example all the common flows are implemented but some corner cases might > > not be built yet: > > > Level 2 > > > > > > The KIP is now usable, but it might not be completed yet. > > > > So the main difference between Level 1 and 2 is that in level 1 the > feature > > can't be used. In level 2 let's say the common flows are. Level 3 all > flows > > (common and corner cases) are implemented. > > > > Does that make sense? > > > > > > Best, > > > > ------------------ > > Josep Prat > > Open Source Engineering Director, Aiven > > josep.p...@aiven.io | +10491715557497 | 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 Mon, Aug 26, 2024, 19:05 Colin McCabe <cmcc...@apache.org> wrote: > > > > > On Mon, Aug 26, 2024, at 08:17, Viktor Somogyi-Vass wrote: > > > > Hi all, > > > > > > > > A couple of additional questions/suggestions regarding the KIP: > > > > > > > > VS1. Testing: you wrote about testing only on level 4 but I think we > > > should > > > > add some testing criteria to each one to ensure that it meets > > > > those requirements specified by the given level and it is gradually > > more > > > > mature. For instance for level 1 I think we may not need to do any > > > > integration testing. For level 2 I think we should at least have > happy > > > path > > > > integration tests where applicable and do full integration testing on > > > level > > > > 3. Of course smaller KIPs may skip level 2 as you mentioned or have > > > > different testing requirements, so it may not be applicable > everywhere. > > > > > > > > VS2. Documentation: I think documentation and user resources > (tutorial) > > > is > > > > also a bit similar. On level 1 and maybe 2 I wouldn't expect any > > > > documentation but I would be happy with a feature doc on level 3 and > > > level > > > > 4 may also need to provide examples (if applicable). For instance in > > the > > > > case of a KRaft or MM2 level feature, I would only consider it level > 4 > > > > (among other things) if it had a very extensive documentation and > > > > tutorials/examples for users. > > > > > > > > VS3. Checklist: I guess the bigger point of view of my previous > points > > is > > > > that we should create a checklist of a few items (not too many) that > > KIPs > > > > graduating to that level should fulfill (besides the ones on the > > previous > > > > level) to ensure it is really some sort of an objective graduation. > In > > my > > > > mind it looks like this: > > > > Level 1: > > > > - the KIP has to be accepted > > > > Level 2: > > > > - the feature is usable > > > > - has integration tests for the happy path > > > > - unit tests exists that cover the existing functionality > > > > - some minimal documentation exists for early adopters > > > > > > Hi Viktor, > > > > > > I don't think it makes sense to require that "the feature is usable" at > > > level 2. As I understand it, this level just means that the feature is > > > under devlopment. Most features are not usable on day 1 of development. > > > Similarly, documentation is usually the thing that gets written last. > It > > is > > > not reasonable to expect it to be written during development, when the > > > feature might be changing from week to week. > > > > > > > Level 3: > > > > - stable API > > > > - integration tests cover all paths > > > > - unit tests cover added functionality > > > > - documentation exists for users > > > > Level 4: > > > > - extensive documentation exists for users with examples or > tutorials > > > if > > > > needed > > > > - unit tests cover added functionality > > > > - integration test suites covering the KIPs functionality > > > > - system tests if needed > > > > > > I think we should avoid turning this into a code quality checklist. It > > > really should be about when the feature is ready to be used by > end-users. > > > And a lot of KIPs don't involve code at all, like deprecating some > > > configuration, changing the Scala version, changing the JDK version, > etc. > > > > > > We already added a section about "Testing" to each KIP. Really the > > > requirement to reach the last level should be that you did all the > > testing > > > that you promised to do. If that testing was insufficient, then that > > > problem should be identified during the KIP discussion. > > > > > > > > > > > PS. I like the alternative names :) > > > > > > > > > > Which names are "the alternative names" to you? :) > > > > > > As I said earlier, I'm not happy with the "level N" jargon since I > don't > > > think people outside this dev mailing list will understand it. Most > users > > > will react to "that feature is on level 2" with incomprehension. On the > > > other hand, if you tell them that the feature is "alpha," they'll get > > what > > > you're saying. Let's not add jargon that our users won't understand. > > > > > > best, > > > Colin > > > > > > > > > > Best, > > > > Viktor > > > > > > > > On Mon, Aug 26, 2024 at 11:20 AM Josep Prat > > <josep.p...@aiven.io.invalid > > > > > > > > wrote: > > > > > > > >> Hi David, > > > >> > > > >> Thanks for the feedback! > > > >> > > > >> DA1. I'm fine not exposing level 1, but I think it was worth having > it > > > for > > > >> completeness-sake as you mention. This level is probably more of a > > > >> technicality but my state-machine brain needs the initial state. > > > >> > > > >> DA2. Yes, this is the key difference between level 3 and 4. Not all > > > >> features need to go through level 3, for example, refactoring APIs > or > > > >> adding new public methods for convenience can directly go to level > 4. > > > So I > > > >> see level 3 as the default "rest" level for "big" features until we > > gain > > > >> certainty. While "simpler" features could go up to level 4 directly. > > > >> > > > >> DA3. This is a good suggestion. I don't know if we can be too > > > prescriptive > > > >> with this. It all would boil down to the amount and quality of > > feedback > > > >> from the early adopters. Now the KIP mentions that levels can only > be > > > >> changed in minors and majors, this means that if we don't say > anything > > > >> else, the minimum "baking time" would be 1 minor release. This is > the > > > >> technical lower limit. We could mention that we encourage to gather > > > >> feedback from the community for 2 minor releases (the one where the > > > feature > > > >> was released at level 3 and the next minor release). So a feature > > > reaching > > > >> level 3 in Kafka 4.0, could technically change to level 4.1, but it > is > > > >> encouraged to wait at least until 4.2. > > > >> > > > >> DA4. I see your point. I did some archeology to write this KIP and > as > > I > > > >> mention in the motivation, prior 2.8 all features were released as > > what > > > we > > > >> could assume would be production ready. If I'm not mistaken, the > > policy > > > for > > > >> critical bug backporting has always been 3 releases. I wouldn't > change > > > this > > > >> in this KIP and leave it for further KIPs to raise this if it turns > > out > > > to > > > >> be necessary. > > > >> > > > >> DA5. We could potentially do the following state lifecycle: "Under > > > >> Discussion", "Voting", "Rejected", "Accepted" (this would equal > level > > > 1), > > > >> "level 2", "level 3", level 4". What do you think? > > > >> > > > >> DA6. This was my intention with the "Graduation Steps Log". Each KIP > > > that > > > >> needs in between states, would have this and users could see when > each > > > KIP > > > >> transitioned to each level. If you want to have the reverse lookup > > (per > > > >> release). We could add a new section in the "upgrading" > documentation > > > >> section. We could include all KIPs with their state in there. > > > >> > > > >> Let me know what you think! > > > >> > > > >> Best! > > > >> > > > >> On Sun, Aug 25, 2024 at 11:50 PM David Arthur <mum...@gmail.com> > > wrote: > > > >> > > > >> > Josep, thanks for the KIP! I think clear definitions of feature > > > stability > > > >> > will be a boon to our users and developers. > > > >> > > > > >> > DA1. I agree with others in this thread that three levels is > > probably > > > >> > sufficient. Anything before "usable" is not really necessary to > > define > > > >> from > > > >> > a user's perspective. It's fine to include this definition in the > > KIP > > > for > > > >> > completeness-sake, but I don't think we should not expose it as > part > > > of > > > >> the > > > >> > "feature stability API". > > > >> > > > > >> > DA2. To me, one of the biggest differences between 3 and 4 is > > feedback > > > >> from > > > >> > production experience. We can do our best to test new things, but > > > until > > > >> > something is used "in anger" we will not really be able to say > it's > > > ready > > > >> > for production. This is especially true for large features. I > would > > > say > > > >> > level 3 is what we (Kafka) normally call a new feature. We can't > > > really > > > >> > promote a feature to level 4 until we (or our users) have gained > > > >> production > > > >> > experience with it. This means we will rely on early adopters for > > > >> feedback > > > >> > regarding new features. > > > >> > > > > >> > DA3. Related to the DA2, Should we consider a number of releases > or > > > >> amount > > > >> > of time it takes for a feature to move from Level 3 to 4? Some > > minimum > > > >> > "bake time" essentially > > > >> > > > > >> > DA4. I think we should also talk about bug backports in this KIP. > > > Once we > > > >> > announce something as level 4, what is our bug backport policy? > > > >> > Unofficially, I think we do something like two minor releases. For > > > >> example, > > > >> > if we promoted a feature to level 4 in 4.1, and trunk is now on > 4.7 > > -- > > > >> how > > > >> > far back do we backport critical fixes? Every release since the > > level > > > 4 > > > >> > promotion, or only a few? > > > >> > > > > >> > DA5. Should we add new states for our KIPs? Today, we end at > > Adopted. > > > It > > > >> > might make sense to have new states corresponding to the feature > > > >> stability. > > > >> > It would also be good to capture this information in the KIP > itself > > > >> under a > > > >> > new "History" section. > > > >> > > > > >> > DA6. How will we convey this information to our users? Right now, > > > >> > announcements of features are scattered across release notes. It > > > would be > > > >> > really nice if we could come up with a way to easily look up the > > state > > > >> of a > > > >> > feature/KIP at a particular version. > > > >> > > > > >> > Cheers, > > > >> > David A > > > >> > > > > >> > On Fri, Aug 23, 2024 at 1:08 PM Colin McCabe <cmcc...@apache.org> > > > wrote: > > > >> > > > > >> > > On Thu, Aug 22, 2024, at 07:36, Andrew Schofield wrote: > > > >> > > > Hi Josep, > > > >> > > > Thanks for creating this KIP. It looks like a good proposal. A > > few > > > >> > > comments. > > > >> > > > > > > >> > > > AS1: I don’t think features should be able to progress between > > the > > > >> > > levels in > > > >> > > > patch releases. Yes, there may be some bug fixes which mean > that > > > >> > > > the usability of a feature has progressed markedly, but given > > that > > > >> > > > Kafka releases are so frequent, it doesn’t seem too much of a > > > burden > > > >> > > > making features wait until the next minor release to progress > to > > > the > > > >> > > > next level. > > > >> > > > > > > >> > > > > > >> > > Hi Andrew, > > > >> > > > > > >> > > I think that's fine going forward, but we need to clarify that > it > > > only > > > >> > > applies to new features started after this KIP. One reason is > > > because > > > >> the > > > >> > > plan for KIP-853 is to make it production-ready in one of the > > point > > > >> > > releases of 3.9. > > > >> > > > > > >> > > > AS2: While I think that the Graduation Steps Log idea is a > good > > > >> > addition > > > >> > > to > > > >> > > > these more complicated KIPs, but I don’t like release managers > > > having > > > >> > > > to visit all of the KIPs to see what the state of play is. > Each > > > >> release > > > >> > > has > > > >> > > > a release plan on the wiki which people update to add in the > > KIPs. > > > >> > > > I would prefer the KIP authors to use that as the way to > signal > > to > > > >> the > > > >> > > > release manager that their KIPs have attained a particular > > level. > > > >> > > > The Graduation Steps Log is more for the KIP reader to find > out > > > when > > > >> > > > the interesting feature they are reading about was actually > > > delivered > > > >> > > > in a simple way. The KIP author would have to keep these in > > sync, > > > >> > > > which is quite a small burden for something that only changes > a > > > few > > > >> > times > > > >> > > > at most in the life of a KIP. > > > >> > > > > > >> > > I think realistically, the release managers will have to check > up > > on > > > >> the > > > >> > > status of KIPs... for example, by pinging the people working on > > > them. > > > >> > > Otherwise we'll have stuff stuck in an older state even after > it's > > > >> ready, > > > >> > > because the devs forgot to update it. This is similar to the > work > > > >> release > > > >> > > managers already do to update the release version of KIPs. I > agree > > > that > > > >> > > it's good to encourage the developers to do this on their own > > > >> initiative > > > >> > as > > > >> > > well. > > > >> > > > > > >> > > Also, for KIPs that don't need multiple steps, I wonder if we > need > > > >> > > anything different than what we have now (just a "release > version" > > > >> > field). > > > >> > > > > > >> > > best, > > > >> > > Colin > > > >> > > > > > >> > > > > > > >> > > > AS3: For KIPs which end up with some pieces being completed > > before > > > >> > > others, > > > >> > > > it would be simple to document the sub-features which were > > > delivered > > > >> > > > and graduated at different releases without being too > > prescriptive > > > >> and > > > >> > > > inventing sub-KIPs or whatever. > > > >> > > > > > > >> > > > AS4: I suggest adding to the KIP some statement about feature > > > >> versions, > > > >> > > > configurations and other switches at the various levels. For > > > example, > > > >> > > > if a Kafka feature such as “transaction.version” is used to > > > enable a > > > >> > KIP, > > > >> > > > I suppose it would be introduced at level 3 or later, and > > > switched on > > > >> > > > by default at level 4. The same with unstable APIs - I > supposed > > at > > > >> > > > levels 1 and 2, if there are new RPCs defined, I need to use > > > >> > > > `unstable.api.versions.enable` on the broker to enable them. > > > >> > > > > > > >> > > > AS5: I wonder whether we need to avoid “features” here because > > it > > > >> > > > already has a specific meaning in Kafka (bin/kafka-features.sh > > and > > > >> > > > so on). Maybe this KIP should be “Graduation Steps for KIPs”. > > > >> > > > > > > >> > > > AS6: Typo: Level 3 says “This level is optional, and a feature > > > must > > > >> not > > > >> > > go > > > >> > > > through it”. This should probably say “does not need to”. > > > >> > > > > > > >> > > > AS7: I suggest “Incubation” for level 1. > > > >> > > > > > > >> > > > Thanks, > > > >> > > > Andrew > > > >> > > > > > > >> > > > > > > >> > > >> On 22 Aug 2024, at 08:40, Josep Prat > > <josep.p...@aiven.io.INVALID > > > > > > > >> > > wrote: > > > >> > > >> > > > >> > > >> Hi Matthias, > > > >> > > >> > > > >> > > >> Thanks for your feedback! > > > >> > > >> - Feedback for level 1: > > > >> > > >> Yes, indeed it is almost superfluous, but I decided to add it > > for > > > >> > > >> completeness. A KIP in level 1 might have some PRs that are > > > merged, > > > >> > but > > > >> > > >> it's not yet functional nor complete. For example, only the > > > >> interfaces > > > >> > > have > > > >> > > >> been added. > > > >> > > >> We could also remove level 1, but then KIPs would start > > without a > > > >> > level > > > >> > > >> assigned which is implicitly a level in my opinion. > > > >> > > >> The reason for level 1 in my opinion is to ease the work of > the > > > >> > release > > > >> > > >> manager in understanding if worked KIPs are to be included in > > the > > > >> > > release > > > >> > > >> notes and in the list of released KIPs. > > > >> > > >>> This seems to be little bit confusing. If it's not meant to > be > > > used > > > >> > > >> by anybody, should it not be feature flagged and > disable/hidden > > > from > > > >> > > users > > > >> > > >> completely? > > > >> > > >> Yes, this is correct, most of the time they would be behind a > > > >> feature > > > >> > > flag, > > > >> > > >> or they will be new code paths not reachable yet. Let's take > > > KIP-853 > > > >> > for > > > >> > > >> example, at the moment of Kafka 3.8.0 release, only the > first 6 > > > >> tasks > > > >> > > under > > > >> > > >> https://issues.apache.org/jira/browse/KAFKA-14094 were > > > completed. > > > >> The > > > >> > > >> feature was not usable and not visible for our users. Thus, > > > level 1. > > > >> > > >> > > > >> > > >>> In the end it means, a release does just not contain > anything > > > about > > > >> > it > > > >> > > >> (even if there might be code that was merged), and the KIP > > should > > > >> not > > > >> > be > > > >> > > >> mentioned in the release notes at all, and thus we don't > need a > > > name > > > >> > as > > > >> > > the > > > >> > > >> feature is not graduated into any (useful) level yet. > > > >> > > >> You are totally correct, features in level 1 should not be > > > mentioned > > > >> > in > > > >> > > the > > > >> > > >> release notes. Effectively, the release doesn't contain this > > KIP, > > > >> even > > > >> > > if > > > >> > > >> technically it contains work on this KIP. > > > >> > > >> > > > >> > > >> The way I understand it, dropping this level from the > hierarchy > > > will > > > >> > > mean > > > >> > > >> that KIPs start at no level, and at one point in time go to > > > level X. > > > >> > > This > > > >> > > >> effectively means that KIPs start at an implicit level. Maybe > > > >> calling > > > >> > it > > > >> > > >> level 0 helps to better represent that this is the default > > entry > > > >> > point. > > > >> > > >> > > > >> > > >> - Feedback for term usable > > > >> > > >> Yes this is a good point. But given the variety of features > we > > > >> > create, I > > > >> > > >> don't want to be overly prescriptive and then realize that we > > > don't > > > >> > > >> represent some in there. If we borrow terms from the industry > > > this > > > >> > > could be > > > >> > > >> "Minimum Usable Product"[1]. Usable for a KIP means that it > > > contains > > > >> > at > > > >> > > >> least the minimum amount of functionality that makes it > usable. > > > What > > > >> > > usable > > > >> > > >> means it varies from KIP to KIP. Let's see KIP-853 again, > > > >> > > >> https://issues.apache.org/jira/browse/KAFKA-14094 originally > > > >> > contained > > > >> > > all > > > >> > > >> the work needed for the KIP. After a while, the KIP drivers > > (Jose > > > >> and > > > >> > > >> Colin) agreed to split the tasks in 2 groups, the tasks now > > > present > > > >> > > under > > > >> > > >> KAFKA-14094 and the newly created > > > >> > > >> https://issues.apache.org/jira/browse/KAFKA-17241. > > > >> > > >> I'm open to suggestions on how we can clarify this better, > > > without > > > >> > being > > > >> > > >> too prescriptive and then finding that developers can't > relate > > to > > > >> it. > > > >> > > >> > > > >> > > >> - Feedback for partial releases > > > >> > > >> This is a very good point. This KIP mostly equates features > to > > > KIPs, > > > >> > > which > > > >> > > >> at some high level of abstraction probably holds true. But > you > > > are > > > >> > > >> definitely right, bigger KIPs that define a new capability > > > contain > > > >> > > >> different features. These graduation steps could apply to any > > of > > > the > > > >> > > >> sub-features of a KIP. > > > >> > > >> The bigger and more complex these KIPs are, the more we might > > > want > > > >> to > > > >> > > >> logically break them down in the KIP itself. Maybe these KIPs > > > are in > > > >> > the > > > >> > > >> end sub-KIPs in a KIP, and could each of them follow the same > > > >> > graduation > > > >> > > >> steps defined here. Also if we think about release > > announcements, > > > >> what > > > >> > > did > > > >> > > >> we say about these KIPs that only some parts were completed > in > > a > > > >> > > release? > > > >> > > >> From the list you shared KIP-925: Rack aware task assignment > in > > > >> Kafka > > > >> > > >> Streams > > > >> > > >> < > > > >> > > > > > >> > > > > >> > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-925%3A+Rack+aware+task+assignment+in+Kafka+Streams > > > >> > > > > > > >> > > >> seems to be partially released in 3.6 and then fully released > > in > > > >> 3.7. > > > >> > > >> However, I can't find any trace of KIP-925 in the Kafka 3.6 > > blog > > > >> > > >> announcement. Would it reflect the reality to say that > KIP-925 > > > had > > > >> > > >> different "behaviours" that needed to be implemented and some > > > made > > > >> it > > > >> > > >> completely (level 4) on to Kafka 3.6, while the last one made > > it > > > >> (also > > > >> > > >> level 4) only in Kafka 3.7? > > > >> > > >> We could potentially state that KIPs that contain multiple > > > features > > > >> > > should > > > >> > > >> state those clearly, and the graduation steps would apply to > > > these > > > >> > > instead > > > >> > > >> of the KIP itself. > > > >> > > >> > > > >> > > >> - Feedback for KIPs that are never completed > > > >> > > >> I guess this depends on each particular case but I would like > > > for us > > > >> > to > > > >> > > >> reflect on the situation itself. I think this is something we > > > should > > > >> > > >> address regardless of this KIP in question. If the features > are > > > >> deemed > > > >> > > >> important for the KIP, we should keep the KIP "open" until > this > > > is > > > >> > done. > > > >> > > >> If we would agree that big KIPs can list a collection of > > features > > > >> and > > > >> > > those > > > >> > > >> are the ones graduating, would then this solve this problem? > A > > > KIP > > > >> > will > > > >> > > >> have some of the features marked at level 4 while others > would > > > be at > > > >> > > level > > > >> > > >> 1 (or no level depending on outcome of prior point). > > > >> > > >> > > > >> > > >> - Feedback for when to reach new levels > > > >> > > >> I initially thought the same, level changes can only be > > > triggered in > > > >> > > minors > > > >> > > >> and majors. However, I was thinking that if everything needed > > for > > > >> the > > > >> > > >> feature itself could be done in patch releases why couldn't > the > > > >> > > graduation > > > >> > > >> step change in patch releases as well. > > > >> > > >> For example, let's imagine a fictitious KIP that is on level > 3. > > > All > > > >> > > public > > > >> > > >> API changes have been completed already and their > > implementation > > > is > > > >> > > there. > > > >> > > >> The KIP drivers wanted to seek validation in real scenarios > > > that's > > > >> why > > > >> > > the > > > >> > > >> feature is at level 3 and not 4. Let's keep imagining that > they > > > get > > > >> > > >> multiple satisfactory reports from the community and a couple > > of > > > >> > reports > > > >> > > >> that indicate a performance degradation occurs under > > > circumstance X. > > > >> > > This > > > >> > > >> is fixed and released in the next patch version. Should we be > > > able > > > >> to > > > >> > > >> graduate this feature to level 4 in this patch version? > > > >> > > >> To be honest if people have concerns about this, I'm fine by > > > leaving > > > >> > > this > > > >> > > >> possibly corner case out and only allow graduation changes on > > > major > > > >> > and > > > >> > > >> minors. > > > >> > > >> > > > >> > > >> > > > >> > > >> Let me know what you think > > > >> > > >> > > > >> > > >> Best, > > > >> > > >> > > > >> > > >> [1]: https://www.sarvika.com/2021/06/17/mvp-mlp-mup/ > contains > > > some > > > >> > > >> explanation and comparison of MVP vs MLP vs MUP. > > > >> > > >> > > > >> > > >> On Thu, Aug 22, 2024 at 7:07 AM Matthias J. Sax < > > > mj...@apache.org> > > > >> > > wrote: > > > >> > > >> > > > >> > > >>> Thanks Josep. Couple of comments/questions: > > > >> > > >>> > > > >> > > >>> For Level 1, the KIP says: > > > >> > > >>> > > > >> > > >>>> The feature is not yet stable and it is not meant to be > used > > by > > > >> end > > > >> > > >>> users. > > > >> > > >>> > > > >> > > >>> This seems to be little bit confusing. If it's not meant to > be > > > used > > > >> > by > > > >> > > >>> anybody, should it not be feature flagged and disable/hidden > > > from > > > >> > users > > > >> > > >>> completely? > > > >> > > >>> > > > >> > > >>> Of course, it should not be used in production, but isn't > the > > > goal > > > >> > that > > > >> > > >>> users do try it out and provide early feedback about the > > > feature? > > > >> > > >>> However, this is described on Level 2. So I am really not > sure > > > what > > > >> > > >>> Level 1 is supposed to be, or why we would need it as an > > public > > > >> > > >>> "contract". Later the KIP say > > > >> > > >>> > > > >> > > >>>> Implicitly when a KIP is approved and development starts, > the > > > >> > feature > > > >> > > is > > > >> > > >>> effectively in "Level 1" > > > >> > > >>> > > > >> > > >>> Which really means to me, we should drop this level from the > > > >> "public > > > >> > > >>> hierarchy", as it won't add much (any?) value? > > > >> > > >>> > > > >> > > >>> The propose name "In Development" indicates the same thing > to > > > me. > > > >> In > > > >> > > the > > > >> > > >>> end it means, a release does just not contain anything about > > it > > > >> (even > > > >> > > if > > > >> > > >>> there might be code that was merged), and the KIP should not > > be > > > >> > > >>> mentioned in the release notes at all, and thus we don't > need > > a > > > >> name > > > >> > as > > > >> > > >>> the feature is not graduated into any (useful) level yet. > > > >> > > >>> > > > >> > > >>> > > > >> > > >>> I also find the term "usable" very fuzzy. Can we add more > > color > > > to > > > >> > it? > > > >> > > >>> > > > >> > > >>> > > > >> > > >>> Another thought: we did have cases for KS for which a KIP > was > > > only > > > >> > > >>> partially implemented in a release, but the completed parts > > > where > > > >> > fully > > > >> > > >>> functional, and thus in stage 4. How do we intent to handle > > this > > > >> > going > > > >> > > >>> forward? I would find it rather odd to only release > something > > as > > > >> > stage > > > >> > > 2 > > > >> > > >>> just to follow the process... (as a matter of fact, we still > > > have > > > >> > some > > > >> > > >>> KIPs which never got fully completed but are pending > > completion > > > for > > > >> > > >>> years now, and might frankly never get completed) > > > >> > > >>> > > > >> > > >>> Cf > > > >> > > >>> > > > >> > > >>> > > > >> > > > > > >> > > > > >> > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Streams+KIP+Overview > > > >> > > >>> for examples > > > >> > > >>> > > > >> > > >>> > > > >> > > >>> > > > >> > > >>>> A feature can be promoted to a "higher" level at any > release > > > >> > > (including > > > >> > > >>> patch releases) > > > >> > > >>> > > > >> > > >>> Not sure if this makes sense? To me, a new level can only be > > > >> reached > > > >> > in > > > >> > > >>> a major or minor release? > > > >> > > >>> > > > >> > > >>> > > > >> > > >>> > > > >> > > >>> > > > >> > > >>> -Matthias > > > >> > > >>> > > > >> > > >>> On 8/20/24 6:21 AM, Josep Prat wrote: > > > >> > > >>>> Hi all, > > > >> > > >>>> > > > >> > > >>>> I added a new section in the KIP to specify how to change > the > > > >> > > graduation > > > >> > > >>>> levels for a feature. > > > >> > > >>>> > > > >> > > >>>> Best! > > > >> > > >>>> > > > >> > > >>>> On Mon, Aug 19, 2024 at 4:01 PM Josep Prat < > > > josep.p...@aiven.io> > > > >> > > wrote: > > > >> > > >>>> > > > >> > > >>>>> Hi TengYao and Chia-Ping, > > > >> > > >>>>> > > > >> > > >>>>> I updated the KIP page with examples. > > > >> > > >>>>> > > > >> > > >>>>> Best, > > > >> > > >>>>> > > > >> > > >>>>> On Mon, Aug 19, 2024 at 2:39 PM TengYao Chi < > > > kiting...@gmail.com > > > >> > > > > >> > > >>> wrote: > > > >> > > >>>>> > > > >> > > >>>>>> Hi Josep > > > >> > > >>>>>> > > > >> > > >>>>>> Thanks for the explanation. I see your point. > > > >> > > >>>>>> It makes sense to keep these levels distinct for larger > > > >> > initiatives > > > >> > > >>> like > > > >> > > >>>>>> KIP-853. I agree with your perspective. > > > >> > > >>>>>> > > > >> > > >>>>>> Best regards, > > > >> > > >>>>>> TengYao > > > >> > > >>>>>> > > > >> > > >>>>>> Josep Prat <josep.p...@aiven.io.invalid> 於 2024年8月19日 週一 > > > >> > 下午6:36寫道： > > > >> > > >>>>>> > > > >> > > >>>>>>> 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 mig > > > < > > > https://www.google.com/maps/search/on+between+these+two+levels+mig?entry=gmail&source=g > > >ht > > > 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 > > > >> > > >>>>> > > > >> > > >>>> > > > >> > > >>>> > > > >> > > >>> > > > >> > > >> > > > >> > > >> > > > >> > > >> -- > > > >> > > >> [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 > > > >> > > > > > >> > > > > >> > > > > >> > -- > > > >> > David Arthur > > > >> > > > > >> > > > >> > > > >> -- > > > >> [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 > > > >> > > > > > > > > -- > -David > -- [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
