Thank you very much for the votes.
The vote is now closed with 3 binding +1 (Becket Qin, Jun Rao and Jason
Gustafson).
On Mon, Dec 11, 2017 at 11:21 PM, Jason Gustafson
wrote:
> +1. Thanks for the KIP.
>
> On Mon, Dec 11, 2017 at 1:54 AM, charly molter
> wrote:
>
> > Hi,
> > The KIP has been u
+1. Thanks for the KIP.
On Mon, Dec 11, 2017 at 1:54 AM, charly molter
wrote:
> Hi,
> The KIP has been updated. As it has change should I restart the vote?
>
> In any case I'm still missing one binding vote if anyone wants to help.
> Thanks!
>
> On Wed, Dec 6, 2017 at 6:13 PM, charly molter
> w
Hi,
The KIP has been updated. As it has change should I restart the vote?
In any case I'm still missing one binding vote if anyone wants to help.
Thanks!
On Wed, Dec 6, 2017 at 6:13 PM, charly molter
wrote:
> Sounds good I'll update the KIP
>
> On Wed, Dec 6, 2017 at 6:04 PM, Becket Qin wrote:
Sounds good I'll update the KIP
On Wed, Dec 6, 2017 at 6:04 PM, Becket Qin wrote:
> Hi Charly,
>
> Personally I prefer emitting both and deprecate old one. This does not
> block on the 2.0 release and we don't need to worry about more users
> picking up the old metric in 1.1 release.
>
> Thanks,
Hi Charly,
Personally I prefer emitting both and deprecate old one. This does not
block on the 2.0 release and we don't need to worry about more users
picking up the old metric in 1.1 release.
Thanks,
Jiangjie (Becket) Qin
On Tue, Dec 5, 2017 at 4:08 AM, charly molter
wrote:
> Thanks Jun and
Thanks Jun and Becket!
I think your point about 1.0 vs 2.0 makes sense I can update the KIP to
reflect this.
What's the process for 2.0 contributions as I can see that trunk is 1.1 and
no 2.x branch?
Here's what I can do:
- Not write the code change until trunk moves to 2.0.
- Write the change b
Thanks for the KIP, Charly.
+1. The proposal looks good to me. I agree with Jun that it is better to
make the metrics consistent with other metrics. That being said, arguably
this is a backwards incompatible change. Since we are at 1.0, backwards
incompatible changes are supposed to be in 2.0. Not
Hi, Jiangjie,
Since you proposed the original KIP-92, do you want to see if this KIP
makes sense?
Thanks,
Jun
On Wed, Nov 22, 2017 at 2:48 AM, charly molter
wrote:
> Hi,
>
> I would like to start the voting thread for KIP-225.
> This KIP proposes to correct some lag metrics emitted by the con
Hi, Charly,
Thanks for the proposal. Since the per partition level metric is likely not
widely used, it's probably better to fix the metric name and make it more
consistent. +1 from me.
We probably want to document this change in the upgrade section.
Jun
On Wed, Nov 29, 2017 at 2:45 AM, charly
Hi,
Just a reminder that this vote is open. Let me know if you think this is
not a valuable change.
Thanks!
On Wed, Nov 22, 2017 at 10:48 AM, charly molter
wrote:
>
> Hi,
>
> I would like to start the voting thread for KIP-225.
> This KIP proposes to correct some lag metrics emitted by the con
Hi,
I would like to start the voting thread for KIP-225.
This KIP proposes to correct some lag metrics emitted by the consumer.
The KIP wiki is here:
https://cwiki.apache.org/confluence/x/uaBzB
The discussion thread is here:
http://search-hadoop.com/m/Kafka/uyzND1F33uL19AYx/threaded
Also could
11 matches
Mail list logo
