review" interchangeably :)
> >>
> >> -David
> >>
> >> On Wed, Oct 2, 2024 at 8:09 AM Andrew Schofield <
> >> andrew_schofield_j...@outlook.com> wrote:
> >>
> >>> Hi Josep,
> >>> Thanks for applying the first c
nt already and the sequence is pretty clear
based on the names themselves.
Thanks,
Andrew
From: Josep Prat
Sent: 02 October 2024 09:10
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-1081: Graduation Steps for Features
Hi all,
I think the discussion
gt; >
> > Thanks,
> > Andrew
> >
> >
> > From: Josep Prat
> > Sent: 02 October 2024 09:10
> > To: dev@kafka.apache.org
> > Subject: Re: [DISCUSS] KIP-1081: Graduation Steps for Features
> >
> > Hi a
t already and the sequence is pretty clear
> based on the names themselves.
>
> Thanks,
> Andrew
>
> ____________
> From: Josep Prat
> Sent: 02 October 2024 09:10
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] KIP-1081: Graduation Steps for Features
>
October 2024 09:10
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-1081: Graduation Steps for Features
Hi all,
I think the discussion regarding the steps has winded down and we've
reached a good enough consensus. With that out of the way, we can now start
to paint our bike shed, a.k.a. choos
Hi all,
I think the discussion regarding the steps has winded down and we've
reached a good enough consensus. With that out of the way, we can now start
to paint our bike shed, a.k.a. choose the names for each phase.
As we mentioned, step number 1 is virtual and doesn't really need a name.
Step 2'
Hi all!
I did come around and wrote the feedback pending in the KIP itself. Please
take another read! I added a section attempting to define the term
"usable". Also I applied the feedback.
Thanks!
On Wed, Sep 4, 2024 at 1:34 AM Colin McCabe wrote:
> On Fri, Aug 30, 2024, at 16:40, Matthias J. S
On Fri, Aug 30, 2024, at 16:40, Matthias J. Sax wrote:
> Great discussion. Also wanted to follow up with a few things.
>
>
> I believe the term "usable" is not well defined leading to confusion...
> I agree with Viktor that "usable" in the context of level 2 should just
> mean: I can enable the f
Great discussion. Also wanted to follow up with a few things.
I believe the term "usable" is not well defined leading to confusion...
I agree with Viktor that "usable" in the context of level 2 should just
mean: I can enable the feature and it does something... not more, not
less. It might cr
On Mon, Aug 26, 2024, at 10:51, Josep Prat 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"
>
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 :
Hi Colin,
>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
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, b
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
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 requiremen
Hi Viktor,
Thanks for your feedback!
I agree with your points. I didn't originally want to write it so focused
on coding changes so it fits all sorts of KIPs. For example dropping or
adding a Scala or Java version, there are no tests (unit, integration or
system) needed for the specific change, "
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 in
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 a
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
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
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
> th
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
Hi Andrew,
thanks for the feedback!
AS1: I'm fine with it. Updated the KIP.
AS2: I think both steps are needed. I agree with you that KIP authors
should keep the release plan page up-to-date with the status of their KIP.
However, as a user of the KIP, having a graduation steps log would help
und
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
Ka
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
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
co
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 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 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 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 perspect
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 於 2024年8月19日 週一 下午6:36寫道：
> Hi TengYao,
>
> I get your point. I think smaller features defini
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 signa
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 "usab
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 D
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 stor
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
material
34 matches
Mail list logo
