I only raised the idea of barrier to entry regarding the template. I did not state or even really imply that it should affect this initiative in general. Please do not feel obligated to discuss that concept further if we're all on the same page RE not adding to the template.
On Wed, Jul 31, 2024, 22:02 Matthias J. Sax <mj...@apache.org> wrote: > Hi, > > thanks for starting this discussion. It's for sure useful. > > I don't care too much about the naming personally, it just should be > well defined. > > I agree to Josep, that I don't think we would need to change the KIP > template. A KIP is a design doc for the full feature, and should not > concern itself with what state is covered in which release. (As a matter > of fact, most KIPs don't even include their release version -- we only > track it in the top-level KIP overview page...) > > It might be useful though, to add information about different stages in > the KIP overview page, which atm only says "released in version 3.8" > what seems not to be fined grained enough, and hard to reason about. For > something like KIP-848 this should be simpler to achieve as it's single > KIP. For KRaft which actually is a high level umbrella KIP with many > child KIPs it's much harder to reason about it though. Maybe the table > we use right now it not the right way for stuff like this and we should > just track this differently (not sure right now how to be fair). > > Keeping entry level low, seems not to be a concern, given that new > contributes would most likely work on smaller KIPs which are completed > in a single release and thus don't require a more complex workflow and > tracking. > > > -Matthias > > On 7/31/24 12:25 PM, Josep Prat wrote: > > Hi, > > > > I think we can keep the KIP template as is and have the extra process in > > the Jira area. > > > > EA, Preview and Production Ready (I also kind of like this better) feel > to > > me more project management while the KIP document itself is more about > the > > nature of the changes and describing the end result. Except for some KIPs > > that inherently describe a process delivered in stages. > > > > 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 Wed, Jul 31, 2024, 21:12 Andrew Schofield <andrew_schofi...@live.com> > > wrote: > > > >> Hi, > >> I would at least like to see agreement on the various stages. I’m used > to > >> Early Access, then Preview, and finally General Availability, but I > notice > >> that > >> at least one other person on this thread had the order different. Also, > >> General Availability sounds a bit wrong for an open-source project, so > >> maybe > >> Production Ready is better. > >> > >> I’d also like to see some guidelines for what to expect for features in > the > >> various stages. For example, prior to Production Ready, I would not > expect > >> a feature to be turned on by default for a new broker. > >> > >> The point about barrier to entry is fair, but I think this really only > >> applies to > >> a handful of large KIPs which take several releases to come to fruition. > >> I’m sure we didn’t know when KRaft began which release would be the > first > >> in which it would be production ready. I’m sure we decided to release > some > >> early > >> code long before that and having a proper name for that stage seems > >> appropriate. > >> > >> Thanks, > >> Andrew > >> > >>> On 31 Jul 2024, at 18:30, Chris Egerton <fearthecel...@gmail.com> > wrote: > >>> > >>> I'd be hesitant to add too much to the KIP template. We should be > careful > >>> to keep the barrier to entry low for new users. > >>> > >>> On Wed, Jul 31, 2024, 13:24 Kirk True <k...@kirktrue.pro> wrote: > >>> > >>>> Hi Josep, > >>>> > >>>> Thanks for starting this conversation! > >>>> > >>>> Yes, for KIPs that span multiple releases, clearly defining the KIP’s > >>>> state for each release is very important. Perhaps the KIP template > >> could be > >>>> updated to include a “Release Plan” section that includes entries that > >>>> include: > >>>> > >>>> - Version: future Apache Kafka release > >>>> - Status: one of Preview, Early access, Production, etc. > >>>> - Jira: umbrella Jira under which other Jiras relevant to that > release > >>>> are kept > >>>> - Notes: Free-form notes as needed by KIP author > >>>> > >>>> Using KIP-848 as an example, the “Release Plan” section could look > like > >>>> this: > >>>> > >>>> - 3.7 > >>>> - Status: Early access > >>>> - Jira: KAFKA-123 > >>>> - Notes: includes support for user-assigned partitions but not > >>>> subscriptions, server-side regex not included > >>>> - 3.8 > >>>> - Status: Preview > >>>> - Jira: KAFKA-234 > >>>> - Notes: includes support for subscriptions and lots of bug fixes > >>>> - 4.0 > >>>> - Status: Production > >>>> - Jira: KAFKA-345 > >>>> - Notes: includes feature parity with “CLASSIC” consumer groups > >>>> > >>>> Of course, the contents of the “Release Plan” section may need to > change > >>>> over time, and it’s important that the KIP author(s) update it > >> accordingly. > >>>> > >>>> Just a thought. > >>>> > >>>> Thanks, > >>>> Kirk > >>>> > >>>>> On Jul 31, 2024, at 9:43 AM, Josep Prat <josep.p...@aiven.io.INVALID > > > >>>> wrote: > >>>>> > >>>>> Hi Colin, > >>>>> > >>>>> I'm not attached to any names, I'm happy to change them. > >>>>> But from what I can guess from KIP-848 the order is EA -> Preview -> > GA > >>>>> Maybe I'm mistaken. > >>>>> > >>>>> This is why this discussion is important so we all agree on the > number > >> of > >>>>> steps, order and names. > >>>>> > >>>>> I know finding a universal solution is maybe impossible but if we can > >>>> find > >>>>> one that fits most of the feature releases we had and we are planning > >>>>> currently would be great. > >>>>> > >>>>> 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 Wed, Jul 31, 2024, 18:31 Colin McCabe <cmcc...@apache.org> wrote: > >>>>> > >>>>>> Hi Josep, > >>>>>> > >>>>>> Thanks for bringing up this discussion. > >>>>>> > >>>>>> My impression was that "preview" was earlier than early access. > >>>>>> > >>>>>> In my mind, "preview" somewhat implies that the feature could be > >>>>>> incomplete or partial. For example, if someone said their game was a > >>>>>> "preview" I would expect kind of a demo. > >>>>>> > >>>>>> Early access (EA) means people can "access" it but it's "early". In > >>>> other > >>>>>> words, use at your own risk. > >>>>>> > >>>>>> What you are calling "production ready," I think we've sometimes > >> called > >>>>>> generally available (GA) in the past. I don't have a strong > preference > >>>> on > >>>>>> terms. > >>>>>> > >>>>>> I think no matter how much standardization we do, there will always > >> be a > >>>>>> lot of discretion in these terms :) But maybe this helps clarify how > >>>>>> they've been used in the past? > >>>>>> > >>>>>> best, > >>>>>> Colin > >>>>>> > >>>>>> > >>>>>> On Wed, Jul 31, 2024, at 02:03, Josep Prat wrote: > >>>>>>> Hi Kafka devs, > >>>>>>> > >>>>>>> Lately we started using "early access", "production ready" and also > >>>>>>> "preview" to determine the grade of "production readiness" of the > >>>>>> features > >>>>>>> we deliver to our community. > >>>>>>> However, as far as I know, there is no official definition from the > >>>>>> Apache > >>>>>>> Kafka side on which are the graduation steps for features and what > >> type > >>>>>> of > >>>>>>> "guarantees" each of these offer. > >>>>>>> > >>>>>>> I think we should agree on which terms we should use and what each > of > >>>>>> these > >>>>>>> exactly mean in terms of reliability. So far it seems we have this > >>>>>>> graduation steps: > >>>>>>> - Early Access: Feature is just complete but not yet fully polished > >> and > >>>>>>> maybe not used in production in many environments > >>>>>>> - Preview: Feature was early access before and it underwent at > least > >> a > >>>>>>> cycle of improvements and fixes and it's used in some production > >>>>>>> environments maybe > >>>>>>> - Production ready: Feature is officially rele > <https://www.google.com/maps/search/ady:+Feature+is+officially+rele?entry=gmail&source=g>ased > and it fulfills > >> the > >>>>>>> expected initial needs > >>>>>>> > >>>>>>> Note that we don't offer any guarantees or SLA/SLO in the classical > >>>> term. > >>>>>>> > >>>>>>> Is this something we can agree on? What do those terms mean to you? > >> Do > >>>> we > >>>>>>> need more steps? Or do we need less steps? > >>>>>>> > >>>>>>> Best, > >>>>>>> -- > >>>>>>> [image: Aiven] <https://www.aiven.io/> > >>>>>>> > >>>>>>> *Josep Prat* > >>>>>>> Open Source Engineering Di > >>>> < > >> > https://www.google.com/maps/search/%0A%3E%3E%3E+Open+Source+Engineering+Di?entry=gmail&source=g > >>> rector, > >>>> *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 > >>>>>> > >>>> > >>>> > >> > >> > > >
