st regards
> Sergio Troiano
>
> On Fri, 25 Mar 2022 at 06:50, David Jacot wrote:
>
> > Hi Sergio,
> >
> > I made a suggestion a few weeks ago about the name about the parameter but
> > haven’t got a response for it. Did you consider it?
> >
>
+1 (binding). Thanks for the KIP.
Best,
David
Le ven. 25 mars 2022 à 07:11, Luke Chen a écrit :
> Hi Sergio,
>
> Thanks for the KIP!
> +1(binding) from me.
>
> Thank you.
> Luke
>
> On Fri, Mar 25, 2022 at 1:40 PM Sergio Daniel Troiano
> wrote:
>
> > Hi lads,
> >
> > I would like to start the
have removed the prefixing. It does not bring much anyway as
we are still able to distinguish a custom reason from the default one.
[1] https://github.com/apache/kafka/pull/11873
Best,
David
On Wed, Dec 1, 2021 at 2:17 PM David Jacot wrote:
>
> Hi all,
>
> With 4 binding +1 votes (G
Hi Tom,
Thanks for running the release. I wonder if we should include:
https://github.com/apache/kafka/commit/134c432d6452de1bfb99d0f6b455a58c16bc626a.
This is a follow up of KAFKA-13794. What do you think?
Best,
David
On Fri, Apr 8, 2022 at 6:18 PM Tom Bentley wrote:
>
> Hello Kafka users, de
Thanks for running the release, Tom.
I performed the following validations:
* Verified all checksums and signatures.
* Built from source and ran unit tests.
* Ran the first quickstart steps for both ZK and KRaft.
* Spotchecked the Javadocs.
I noticed the same issues as others on the website. I ch
Thanks for running the release, Bruno.
I performed the following validations:
* Verified all checksums and signatures.
* Built from source and ran unit tests.
* Ran the first quickstart steps for both ZK and KRaft.
* Spotchecked the doc and the Javadocs.
+1 (binding)
Best,
David
On Thu, May 5,
eal-time streaming applications that transform or react
> to the streams of data.
>
>
> Apache Kafka is in use at large and small companies worldwide, including
> Capital One, Goldman Sachs, ING, LinkedIn, Netflix, Pinterest, Rabobank,
> Target, The New York Times, Uber, Yelp, and
Hi,
I created a small KIP to strengthen the AlterPartition API in KRaft mode:
https://cwiki.apache.org/confluence/x/phmhD
Let me know what you think.
Best,
David
Hi Niket,
Thanks for the KIP. I have a few minor comments:
1. We should keep DescribeQuorumResult's constructor package-private
for now in my opinion. We have been debating about this in KIP-692 and
KIP-777 but as we haven't reached a consensus yet, we should be on the
conservative side here.
2.
This KIP is pretty straight forward. I will start a vote on Monday
if no one objects.
Best,
David
On Wed, May 18, 2022 at 5:55 PM David Jacot wrote:
>
> Hi,
>
> I created a small KIP to strengthen the AlterPartition API in KRaft mode:
> https://cwiki.apache.org/confluence/x/p
+1 (binding)
Thanks for the KIP!
David
Le ven. 20 mai 2022 à 21:08, David Arthur a écrit :
> Hey Niket, +1 (binding) from me.
>
> -David
>
> On Thu, May 19, 2022 at 2:07 PM José Armando García Sancio
> wrote:
>
> > Hey Niket,
> >
> > I took a look at the latest KIP. It looks like QuorumInfo.R
+1. Thanks Colin!
On Tue, May 24, 2022 at 4:50 AM Luke Chen wrote:
>
> +1 from me.
> Kraft is coming!!!
>
> Luke
>
> On Tue, May 24, 2022 at 7:26 AM Israel Ekpo wrote:
>
> > +1 (non-binding) from me.
> >
> > I am very happy to finally see this.
> >
> > On Mon, May 23, 2022 at 6:08 PM Jason Gusta
Hi all,
Looking at the current Metrics' API, we have `sensor` which gets or creates
a sensor. How about using `metric` to follow the same naming convention?
Best,
David
On Mon, May 30, 2022 at 9:18 AM Bruno Cadonna wrote:
>
> Hi Sagar,
> Hi Ismael,
>
> what about getOrCreateMetric()?
>
> Best,
Hi all,
Thanks for your feedback.
I just updated the KIP as follows:
* I propose to add a `TopicId` field at the same time while we are bumping
the AlterPartition API version.
* I propose to add the `InShuttingDown` field to the registration records to
track if a broker is in controlled shutdown.
Hi folks,
I'd like to start a vote for KIP-841:
https://cwiki.apache.org/confluence/x/phmhD.
Thanks,
David
PLICA. This is very important for error codes so we
> > can track which ones are returned in which RPC version. I also wonder
>
> Here I'm referring to AlterPartitionResponse.json
>
> cheers,
> Colin
>
> >
> >
> > On Tue, May 31, 2022, at 08:36, David Jacot wrote:
> >> Hi folks,
> >>
> >> I'd like to start a vote for KIP-841:
> >> https://cwiki.apache.org/confluence/x/phmhD.
> >>
> >> Thanks,
> >> David
names?
>
> Ismael
>
> On Tue, May 31, 2022, 6:36 AM David Jacot
> wrote:
>
> > Hi all,
> >
> > Thanks for your feedback.
> >
> > I just updated the KIP as follows:
> > * I propose to add a `TopicId` field at the same time while we are
Hi José,
At the moment, the KIP stipulates that the broker remains in
InControlledShutdown state until it is re-registered with a new
incarnation id. This implies that a broker can be both fenced and in
controlled shutdown state. We could make them mutually exclusive but I
think that there is valu
adataVersion since we are adding a new
> field to a metadata record. Otherwise we might have trouble downgrading the
> software if this field has been serialized.
>
> Cheers,
> David
>
> On Thu, Jun 2, 2022 at 11:04 AM David Jacot
> wrote:
>
> > Hi José,
> >
&g
That's correct.
David
On Fri, Jun 3, 2022 at 2:11 AM José Armando García Sancio
wrote:
>
> David Jacot wrote:
> > At the moment, the KIP stipulates that the broker remains in
> > InControlledShutdown state until it is re-registered with a new
> > incarnation id. T
Thanks all!
The vote passes with binding +1 votes from Colin, David, José and myself.
David
On Fri, Jun 3, 2022 at 2:14 AM José Armando García Sancio
wrote:
>
> Thanks for proposing this improvement David Jacot. I think it is going
> to make the graceful shutdown process much more
Hi José,
KIP-841 has been accepted. Could we add it to the release plan?
Thanks,
David
On Wed, May 11, 2022 at 11:04 PM Chris Egerton wrote:
>
> Hi José,
>
> Could we add KIP-618 (
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-618%3A+Exactly-Once+Support+for+Source+Connectors)
> to th
tion%2Bin%2BDescribeQuorumResponse%2Babout%2BVoter%2BLag&source=gmail-imap&ust=165576000900&usg=AOvVaw3ZhA-Qvc0rZBYddc4u9667>
> >>
> >> Thanks
> >> - Niket
> >>
> >>
> >>> On May 24, 2022, at 2:30 PM, José Armando G
Hi Artem,
The KIP LGTM.
Thanks,
David
On Tue, Jun 21, 2022 at 9:32 PM Artem Livshits
wrote:
>
> If there is no other feedback I'm going to start voting in a couple days.
>
> -Artem
>
> On Fri, Jun 17, 2022 at 3:50 PM Artem Livshits
> wrote:
>
> > Thank you for your feedback. Updated the KIP a
Thanks for the KIP, Artem.
I am +1 (binding).
A small nit: ProducerIdCount should be used in the motivation.
Best,
David
On Thu, Jun 23, 2022 at 10:26 PM Artem Livshits
wrote:
>
> Hello,
>
> I'd like to start a vote on KIP-847
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-847%3A+Add+
Thanks for the KIP.
I read it and I am also worried by the complexity of the new
configurations. They are not easy to grasp. I need to digest it a bit more,
I think.
Best,
David
Le mer. 29 juin 2022 à 02:25, Matthias J. Sax a écrit :
> Thanks for the KIP.
>
> I don't think I fully digested the
Hi Guozhang,
Thanks for the KIP!
I agree with Luke. `requireStable` seems more consistent.
Regarding the kafka-consumer-group command line tool, I wonder if
there is real value in doing it. We don't necessarily have to add all
the options to it but we could if it is proven to be useful. Anyway,
Hi all,
I would like to start a discussion thread on KIP-848: The Next
Generation of the Consumer Rebalance Protocol. With this KIP, we aim
to make the rebalance protocol (for consumers) more reliable, more
scalable, easier to implement for clients, and easier to debug for
operators.
The KIP is h
Thanks for the KIP, Omnia! +1 (binding)
On Wed, Jul 6, 2022 at 5:02 PM Omnia Ibrahim wrote:
>
> Hi,
> Can we have one last binding vote for this KIP, please?
>
> Omnia
>
> On Tue, Jun 28, 2022 at 3:36 PM Omnia Ibrahim
> wrote:
>
> > Thanks, Tom, I have updated the KIP to reflect these minor poin
+1 (binding). Thanks for the KIP! It is a useful addition.
Best,
David
On Wed, Jul 6, 2022 at 9:10 PM Colin McCabe wrote:
>
> +1 (binding).
>
> thanks, Alexandre.
>
> On Mon, Jun 27, 2022, at 05:15, Alexandre Garnier wrote:
> > Hello!
> >
> > A little ping on this vote.
> >
> > Thanks.
> >
> > L
n, the KIP title
> > should also be updated.
> >
> > Luke
> >
> > On Fri, Jun 24, 2022 at 8:33 PM David Jacot
> > wrote:
> >
> > > Thanks for the KIP, Artem.
> > >
> > > I am +1 (binding).
> > >
> > > A smal
SubscribedTopidIds instead of
> > SubscribedTopicNames in ConsumerGroupHeartbeatRequest? Is the idea that
> > since we have to resolve the regex on the server, we can do the same for
> > the topic name? The difference is that sending the regex is more efficient
> > wh
e metadata lookup on the server for both
paths but I do agree with your point. As a second though, using topic
ids may be better here for the delete and recreation case. Also, I
suppose that we may allow users to subscribe with topic ids in the
future because that is the only way to be really robu
API with Pattern, but instead we still use Pattern
> while just documenting that our subscription may be rejected by the server.
> Since the incompatible case is a very rare scenario I felt using an
> overloaded `String` based subscription may be more vulnerable to various
> invalid re
+1. Thanks David.
Le mer. 13 juil. 2022 à 23:43, José Armando García Sancio
a écrit :
> +1. Thanks for volunteering David.
>
> --
> -José
>
lized in the metadata log for various
> reasons (auditability, visibility, consistency, etc.). Similarly, I am not
> sure about automatically deleting configs in a way that they cannot be
> recovered. A good property for modern systems is to minimize the number of
> unrecoverable data
blem is the same because the configs
are also automatically deleted. Things would be different if groups
were a first class resource in the cluster.
Best,
David
On Fri, Jul 15, 2022 at 1:30 PM David Jacot wrote:
>
> Thanks Hector! Our goal is to move forward with specialized API
> i
see this in a lot of other places, so have I understood it incorrectly ?
>
>
> Regarding connect , it might be out of scope of this discussion, but from
> what I understood it would probably be running in client side assignor mode
> even on the new rebalance protocol as it has i
I'll be away from July 18th to August 8th with limited access to my
emails so I will address new comments and questions when I come back.
Cheers,
David
On Fri, Jul 15, 2022 at 2:16 PM David Jacot wrote:
>
> Hi Sagar,
>
> Thanks for your comments.
>
> 1) Yes. That refe
changes to support connect would be similar at a high
> > level
> > >> to
> > >> > the changes in streams mainly because of the Client side assignors
> > being
> > >> > used in both. At an implementation level, we might need to make a lot
> > of
> > >> >
Thanks for the KIP, Justine. The proposal makes sense to me. I am +1 (binding).
Cheers,
David
On Mon, Aug 8, 2022 at 6:18 PM Justine Olshan
wrote:
>
> Hi all,
> I'd like to start a vote for KIP-854: Separate configuration for producer
> ID expiry.
>
> KIP:
> https://cwiki.apache.org/confluence/d
Throwing an UnsupportedVersionException with an appropriate message
seems to be the best option when the new API is not supported and
AllowReplicationFactorChange is not set to the default value.
Cheers,
David
On Mon, Aug 8, 2022 at 6:25 PM Vikas Singh wrote:
>
> I personally like the UVE option
it here for now in order to
ensure that this KIP is compatible with what we will do for Connect in
the future.
Best,
David
On Mon, Aug 8, 2022 at 2:41 PM David Jacot wrote:
>
> Hi all,
>
> I am back from vacation. I will go through and address your comments
> in the coming
;, right?
>
> 6. In "ConsumerGroupDescribe API" section:
> When the group coordinator handle a ConsumerGroupPrepareAssignmentRequest
> request:
> -> It should be "handle a ConsumerGroupDescribe request"
Thanks for reporting the typos. I will fix them.
Best,
David
data() method by plumbing into
> > >> JoinGroupRequestProtocol.
> > >> >
> > >> > I think the changes to support connect would be similar at a high
> > level
> > >> to
> > >> > the changes in streams mainly because of the Cli
That's a great idea. I am +1 as well.
Thanks,
David
On Tue, Aug 9, 2022 at 11:54 PM Guozhang Wang wrote:
>
> +1 as well. I think adding such proofs in the repo could encourage more
> people reviewing and challenging it, helping to improve whenever we see
> fit. Also it helps readers better under
Hi Yash,
You are all set.
Best,
David
On Thu, Aug 11, 2022 at 3:47 PM Yash Mayya wrote:
>
> Hey folks,
>
> I can't currently assign Apache Kafka Jiras to myself and I just discovered
> that someone needs to add me to the contributors list in order for me to be
> able to do that. Could someone p
n I thought connect can also
> > fit
> > > >> into
> > > >> > this new scheme is that even today the connect uses a
> > > WorkerCoordinator
> > > >> > extending from AbstractCoordinator to empower rebalances of
> > > &
broker
> epoch.
>
> Thanks,
> Calvin.
>
> On Fri, Feb 10, 2023 at 6:11 AM David Jacot
> wrote:
>
> > Hi Calvin,
> >
> > 01. Yeah, this should generally not happen. I was wondering if it could
> > happen in the case of a partial failure of a broker for inst
+1 (binding). Thanks for the KIP, Calvin!
On Tue, Feb 14, 2023 at 1:10 AM Jun Rao wrote:
> Hi, Calvin,
>
> Thanks for the KIP. +1
>
> Jun
>
> On Fri, Feb 10, 2023 at 11:03 AM Alexandre Dupriez <
> alexandre.dupr...@gmail.com> wrote:
>
> > +1 (non-binding).
> >
> > Le ven. 10 févr. 2023 à 19:02,
Hi Chia-Ping,
Thanks for the KIP.
I find the configure method in the proposed interface a bit weird for a few
reasons. First, it has a default implementation which suggests that it is
optional but it is not because the InputStream is required. Second, it
diverges from the Configurable interface.
iterator throw an exception?
Thanks,
David
On Sat, Feb 25, 2023 at 10:43 PM Chia-Ping Tsai wrote:
>
>
> On 2023/02/25 08:26:28 David Jacot wrote:
> > Hi Chia-Ping,
> >
> > Thanks for the KIP.
> >
> > I find the configure method in the proposed interface a bit w
Hi Jeff,
Thanks for the KIP! I am really glad that we are finally addressing this
gap in KIP-848. I have a few general comments.
1. Overall, I feel like the important bits are not bold enough in the KIP.
I think that it is good to explain the overall upgrade/downgrade process
and to highlight whe
>> during
> >> > PR review.
> >> >
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-890%3A+Transactions+Server-Side+Defense
> >> >
> >> > Thanks,
> >> > Justine
> >> >
> >> >
t; > > > > > > > > >
> > > > > > > > > > > 4. I completely missed this. Added some notes at the
> end
> > of
> > > > > > > > > "Restrictions
> > > > > > > > >
Thanks for the KIP, Jeff.
+1 (binding)
On Wed, Mar 29, 2023 at 4:48 PM Jeff Kim
wrote:
> Hi all,
>
> I would like to start the vote on KIP-915: Txn and Group Coordinator
> Downgrade Foundation.
>
> KIP:
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-915%3A+Txn+and+Group+Coordinator+D
Hi,
I am not very comfortable with the proposal of this KIP. The main issue is
that changing the number of partitions means that all group metadata is
lost because the hashing changes. I wonder if we should just disallow
changing the number of partitions entirely. Did we consider something like
th
e it is
> > no longer the partition a consumer group resolves to?
> >
> > Thanks,
> > Alexandre
> >
> > Le mar. 4 avr. 2023 à 18:34, Justine Olshan
> > a écrit :
> > >
> > > Hi,
> > >
> > > I'm also a bit unsure
Hi Mickael,
Thanks for the heads up. As raised by Jeff earlier in this thread, we would
like to get the two small patches [1][2] for KIP-915 in 3.5. The PRs are in
review and I should be able to merge them in the next few days. I will
cherry-pick them to the release branch in your create it in the
ent functionality is added with a few unit tests. We
> > > >>> plan to have follow-up PRs on the immediate pending items and also
> > > >>> raise PRs in the next few weeks on unit tests, integration test
> > > >>> framework and several integration tests for many of the
+1 (binding) Thanks for the KIP, Philip!
Le mar. 25 avr. 2023 à 20:23, José Armando García Sancio
a écrit :
> +1. Thanks for the design. Looking forward to the implementation.
>
> On Tue, Apr 25, 2023 at 10:49 AM Jason Gustafson
> wrote:
> >
> > +1 Thanks Philip!
> >
> >
> > On Thu, Apr 13, 202
+1 Thanks, Luke!
Le mer. 26 avr. 2023 à 12:37, Luke Chen a écrit :
> Hi all,
>
> I'd like to volunteer as release manager for the Apache
> Kafka 3.4.1 release.
> If there are no objections, I'll start building a release plan in the
> wiki in the next couple of days.
>
> Thank you.
> Luke
>
Thanks, David. This is a nice addition!
Coming back to the original proposal of using github actions, it may be
possible to run David's script automatically. For instance, we could
trigger an action which pulls the folks who have approved the PR and feed
the script when a comment with `reviewers`
Hi David,
That makes sense. I think that we have been doing this with a few folks.
The more interesting question is how do we decide who could get added as a
collaborator?
Best,
David
On Fri, Apr 28, 2023 at 4:42 AM Luke Chen wrote:
> Hi David,
>
> Thanks for the suggestion. I'm +1.
> This is
Hi Luke,
> Yes, on second thought, I think the new leader election is required to
work
for this new acks option. I'll think about it and open another KIP for it.
It can't be in another KIP as it is required for your proposal to work.
This is also an important part to discuss as it requires the co
Hi Luke,
Thanks for the KIP.
What do we do in the case where a batch is written with
`ignoreMessageAttributes` set to 1, which means that messages won't have
the `attributes`, and is consumed by a consumer which does not understand
this new format? I suppose that we would need to introduce a new
t; min.insync.replicas = 2.
> >>> >
> >>> > - 1. Initial
> >>> > * A(leo=0), B(leo=0), C(leo=0)
> >>> > - 2. Produce a message to A
> >>> > * A(leo=1), B(leo=0), C(leo=0)
> >>> > - 3. Another producer produces a
ke to hear what the community
> thought about it.
> But if the producers and consumers all existed in the same organization,
> which means upgrading producers/consumers for the org's cost saving, should
> be a reasonable motivation.
>
> Thanks.
> Luke
>
>
> On
e the KIP, too.
>
> Thank you.
> Luke
>
> On Fri, May 12, 2023 at 4:48 PM David Jacot
> wrote:
>
> > Hi Luke,
> >
> > I disagree with this because we don't need the leader election change on
> > its own if we don't do this KIP. They have to go tog
Hi Josep,
Thanks for bringing this up. I agree that we should clean it up. I think
that we should set up an automatic process to flag and then to close stale
pull requests. For instance, we could use a github action [1] for this. I
imagine that we could configure it to mark a pull request as stale
Hey Greg,
Thanks for bringing this up.
I am not sure to understand the benefit of the parallele trigger of a
subset of the tests. Indeed, they will be more likely to pass but the
downside is that folks may start to only rely on that signal and commit
without looking at the full test suite. This s
Thanks, David. I left a few comments in the PR.
-David
Le ven. 9 juin 2023 à 15:31, David Arthur
a écrit :
> Hey all, I just wanted to bump this one more time before I merge this PR
> (thanks for the review, Josep!). I'll merge it at the end of the day today
> unless anyone has more feedback.
>
Hi Divij,
Thanks for the release plan.
I wonder if we should wait a little more as 3.5.0 was released on June
15th. Releasing 3.5.1 a month after seems not enough in order to have time
to catch bugs in 3.5.0. I think that we usually release the first minor
release ~3 months after the major one. I
Hi Mayank,
Thanks for the KIP. This is an interesting idea that I have been thinking
about for a long time so I am happy to see it. The gain is smaller than I
expected but still worth it in my opinion.
01. In the FetchResponse, what's the reason for using version `12+` for the
new tagged field `N
Hi Erik,
Thanks for the KIP. I would like to better understand the motivation of
this KIP. I am not familiar with async runtimes so please excuse me if I
ask stupid questions.
Could you elaborate a bit more on why the callbacks must be ran in another
thread vs in the invoker thread? This is not c
Hi Mayank,
01. Hum... I understand your reasoning. I think that this is mainly
beneficial for clients lagging behind in terms of supported versions.
However, it is the opposite for the java client which is up to date.
Personally, I would rather prefer to bump both versions and to add the
tagged fi
rsion 12, but
> only Java client at version 16 will support it. But that's the best we can
> do.
>
>
>
>
>
>
> On Mon, Jul 24, 2023 at 3:32 PM David Jacot
> wrote:
>
> > Hi Mayank,
> >
> > 01. Hum... I understand your reasoning. I think t
Hi Thomas,
Thanks for the KIP. Overall, the KIP looks good to me.
I have only one question: The FindCoordinator API only supports
resolving one group id at the time. If we want to get the offsets for
say N groups, that means that we have to first issue N FindCoordinator
requests, wait for the res
IP looks good.
> >
> > David,
> > I started working on exactly that a few weeks ago:
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-699%3A+FindCoordinators
> > I hope to complete my draft and start a discussion later on this week.
> &
Thanks for the KIP, Tom.
+1 (binding)
Best,
David
On Wed, Jan 27, 2021 at 11:12 AM Rajini Sivaram
wrote:
> +1 (binding)
>
> Thanks for the KIP, Tom.
>
> Regards,
>
> Rajini
>
>
> On Tue, Jan 26, 2021 at 9:51 AM Thomas Scott wrote:
>
> > Hey all,
> >
> > I'd like to start the vote for
> >
> h
Thanks for the KIP, Mickael. +1 (binding)
On Mon, Mar 1, 2021 at 11:53 AM Tom Bentley wrote:
> +1 (non-binding), thanks Mickael.
>
> On Thu, Feb 25, 2021 at 6:32 PM Mickael Maison
> wrote:
>
> > Hi,
> >
> > I'd like to start a vote on KIP-699 to support resolving multiple
> > coordinators at a
Congrats Chia-Ping! Well deserved.
On Mon, Mar 15, 2021 at 5:39 AM Satish Duggana
wrote:
> Congrats Chia-Ping!
>
> On Sat, 13 Mar 2021 at 13:34, Tom Bentley wrote:
>
> > Congratulations Chia-Ping!
> >
> > On Sat, Mar 13, 2021 at 7:31 AM Kamal Chandraprakash <
> > kamal.chandraprak...@gmail.com>
Congrats, Tom!
On Tue, Mar 16, 2021 at 7:40 AM Kamal Chandraprakash <
kamal.chandraprak...@gmail.com> wrote:
> Congrats, Tom!
>
> On Tue, Mar 16, 2021 at 8:32 AM Konstantine Karantasis
> wrote:
>
> > Congratulations Tom!
> > Well deserved.
> >
> > Konstantine
> >
> > On Mon, Mar 15, 2021 at 4:52
Hi Andrei,
Thanks for the KIP.
Should we consider adding the setting in the clients as well? I think that
it is also enabled by default in the clients. Could it be useful?
Best,
David
Le ven. 19 mars 2021 à 13:41, Ismael Juma a écrit :
> Hi Andrei,
>
> I would start the vote on Monday if ther
+1 (binding)
Thanks for the KIP!
On Mon, Mar 22, 2021 at 8:29 AM Manikumar wrote:
> +1 (binding)
>
>
>
> On Mon, Mar 22, 2021 at 9:42 AM Gwen Shapira
> wrote:
>
> > Woot!
> > +1
> >
> > On Sat, Mar 20, 2021, 10:41 AM Ryanne Dolan
> wrote:
> >
> > > Hey y'all, I'm starting the vote on KIP-720,
Thanks for the KIP, Tom. I agree that this is a good step forward.
+1 (binding)
David
On Mon, Mar 29, 2021 at 5:58 PM Ryanne Dolan wrote:
> +1, thanks!
>
> On Mon, Mar 29, 2021, 10:54 AM Ismael Juma wrote:
>
> > Thanks for the KIP, +1 (binding).
> >
> > Ismael
> >
> > On Mon, Mar 29, 2021 at
Thanks for the KIP, Jason. The proposed changes sound good to me.
Best,
David
On Tue, Apr 27, 2021 at 2:52 AM Satish Duggana
wrote:
> Tthanks Jason for the clarification.
>
> On Tue, 27 Apr 2021 at 05:42, Jason Gustafson
> wrote:
> >
> > Hi Satish,
> >
> > Typically we update the upgrade notes
Hey Thomas,
Thanks for the KIP. I have few comments/questions about it:
1. It would be great if we could better explain why we need this in
the motivation. At the moment, it only explains what will be added.
2. You plan to add the `MAX_TIMESTAMP` constant to tell the
broker to return the maximum
+1 (binding)
Thanks for the KIP.
On Thu, Apr 29, 2021 at 2:27 AM Bill Bejeck wrote:
> Thanks for the KIP Jason, +1(binding)
>
> -Bill
>
> On Wed, Apr 28, 2021 at 7:47 PM Guozhang Wang wrote:
>
> > +1. Thanks Jason！
> >
> > On Wed, Apr 28, 2021 at 12:50 PM Gwen Shapira >
> > wrote:
> >
> > > I
code, the sentinel
> > would be interpreted as a timestamp query and it looks like it would end
> up
> > returning the smallest timestamp ;).
> >
> > A second thought I had is whether it would be useful to include the
> > timestamp type in the response. Otherwi
+1 (binding)
Thanks for the KIP, Tom.
Best,
David
On Fri, Apr 23, 2021 at 12:42 PM Thomas Scott
wrote:
> Hey all,
>
> I'm starting the voting on KIP-734.
>
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-734%3A+Improve+AdminClient.listOffsets+to+return+timestamp+and+offset+for+the+
Hi Ryan,
Thanks for the KIP.
+1 for adding RegisteredBrokerCount to the ZK controller as well. This
would be really helpful.
Best,
David
On Fri, Jun 4, 2021 at 12:44 AM Colin McCabe wrote:
> Hi Ryan,
>
> Thanks for the KIP. I think it would be good to provide the
> RegisteredBrokerCount metri
+1 (binding)
Thanks for the KIP, Ismael!
Le mer. 9 juin 2021 à 11:06, Mickael Maison a
écrit :
> +1 (binding)
> Thanks for the KIP
>
> On Tue, Jun 8, 2021 at 9:15 AM Bruno Cadonna wrote:
> >
> > Hi Ismael,
> >
> > Thank you for the KIP!
> >
> > +1 (binding)
> >
> > Best,
> > Bruno
> >
> > On 0
+1 (binding), Thanks!
Le jeu. 10 juin 2021 à 05:52, Gwen Shapira a
écrit :
> +1 (binding)
>
> Exciting to see this.
>
> On Wed, Jun 9, 2021, 11:29 AM Ismael Juma wrote:
>
> > Hi all,
> >
> > Consensus was reached in the discussion thread and part of what is
> proposed
> > has to happen by 3.0,
+1 (binding), thanks!
On Thu, Jun 10, 2021 at 3:17 AM Colin McCabe wrote:
> +1 (binding).
>
> Looking forward to 4.0 (heh)
>
> best,
> Colin
>
> On Wed, Jun 9, 2021, at 02:45, Tom Bentley wrote:
> > Hi Ismael,
> >
> > Thanks for the KIP, +1 (binding).
> >
> > Cheers,
> >
> > Tom
> >
> > On Wed,
rollers?
> >> Wouldn't it make sense to have one metric that abstracts the
> >> implementation
> >> detail?
> >>
> >> On Mon, Jun 7, 2021 at 2:29 PM Ryan Dielhenn >> .invalid>
> >> wrote:
> >>
> >> > Hey Coli
+1 (binding)
Thanks for the KIP!
Le mar. 15 juin 2021 à 04:30, Israel Ekpo a écrit :
> Xavier, I just responded.
>
> On Mon, Jun 14, 2021 at 1:58 PM Xavier Léauté >
> wrote:
>
> > I had one quick question in the discussion thread. Any chance we can
> > provide some thought there?
> >
> > On Th
Congrats, Konstantine. Well deserved!
Best,
David
On Mon, Jun 21, 2021 at 6:14 PM Ramesh Krishnan
wrote:
> Congrats Konstantine
>
> On Mon, 21 Jun 2021 at 8:58 PM, Mickael Maison
> wrote:
>
> > Hi,
> >
> > It's my pleasure to announce that Konstantine Karantasis is now a
> > member of the Kafk
Hi,
I'd like to volunteer to be the release manager for the next bugfix
release, 2.8.1.
I created the release plan on the wiki:
https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+2.8.1
Best,
David
e the vote.
> Now that things have quieted down a bit, let's restart the vote!
>
> Note that I made some minor changes to the KIP after some offline
> discussion with Ryan Dielhenn and David Jacot. Specifically, I added a
> metric for the number of fenced brokers.
>
>
301 - 400 of 1197 matches
Mail list logo
