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 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
