Re: [VOTE] KIP-365: Materialized, Serialized, Joined, Consumed and Produced with implicit Serde

[Joan Goyeau]

I see!
Thanks for the explanation Matt.

On Sun, 16 Sep 2018 at 20:10 Matthias J. Sax  wrote:

> People cannot pick if their vote is binding or not. If a committer
> (https://kafka.apache.org/committers) votes, it's binding; otherwise, not.
>
> Thus, there is no default -- it depends who votes.
>
>
> -Matthias
>
>
> On 9/13/18 2:41 PM, Joan Goyeau wrote:
> > Ok so a +1 is non binding by default.
> >
> > On Tue, 11 Sep 2018 at 17:25 Matthias J. Sax 
> wrote:
> >
> >> I only count 3 binding votes (Guozhang, Matthias, Damian). Plus 4
> >> non-binding (John, Ted, Bill, Dongjin) -- or 5 if you vote your own KIP
> :)
> >>
> >> -Matthias
> >>
> >> On 9/11/18 12:53 AM, Joan Goyeau wrote:
> >>> Ok, so this is now accepted.
> >>>
> >>> Binding votes: +5
> >>> Non-binding votes: +2
> >>>
> >>> Thanks
> >>>
> >>> On Wed, 5 Sep 2018 at 21:38 John Roesler  wrote:
> >>>
> >>>> Hi Joan,
> >>>>
> >>>> Damian makes 3 binding votes, and the vote has been open longer than
> 72
> >>>> hours, so your KIP vote has passed!
> >>>>
> >>>> It's customary for you to send a final reply to this thread stating
> that
> >>>> the vote has passed, and stating the number of binding and non-binding
> >> +1s.
> >>>>
> >>>> Also please update the current state to Accepted here:
> >>>>
> >>>>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-365%3A+Materialized%2C+Serialized%2C+Joined%2C+Consumed+and+Produced+with+implicit+Serde
> >>>>
> >>>> And move your kip into the Adopted table here:
> >>>>
> >>>>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-365%3A+Materialized%2C+Serialized%2C+Joined%2C+Consumed+and+Produced+with+implicit+Serde
> >>>> (release will be 2.1)
> >>>>
> >>>> And finally, move it to Accepted here:
> >>>> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Streams
> >>>>
> >>>> Lastly, you might want to make another pass over the PR and call for
> >> final
> >>>> reviews.
> >>>>
> >>>> Thanks so much for managing this process,
> >>>> -John
> >>>>
> >>>> On Mon, Sep 3, 2018 at 11:00 AM Damian Guy 
> >> wrote:
> >>>>
> >>>>> +1
> >>>>>
> >>>>> On Sun, 2 Sep 2018 at 15:20 Matthias J. Sax 
> >>>> wrote:
> >>>>>
> >>>>>> +1 (binding)
> >>>>>>
> >>>>>> On 9/1/18 2:40 PM, Guozhang Wang wrote:
> >>>>>>> +1 (binding).
> >>>>>>>
> >>>>>>> On Mon, Aug 27, 2018 at 5:20 PM, Dongjin Lee 
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> +1 (non-binding)
> >>>>>>>>
> >>>>>>>> On Tue, Aug 28, 2018 at 8:53 AM Bill Bejeck 
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>>> +1
> >>>>>>>>>
> >>>>>>>>> -Bill
> >>>>>>>>>
> >>>>>>>>> On Mon, Aug 27, 2018 at 3:24 PM Ted Yu 
> >>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> +1
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Aug 27, 2018 at 12:18 PM John Roesler <
> j...@confluent.io>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> +1 (non-binding)
> >>>>>>>>>>>
> >>>>>>>>>>> On Sat, Aug 25, 2018 at 1:16 PM Joan Goyeau 
> >>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>>
> >>>>>>>>>>>> We want to make sure that we always have a serde for all
> >>>>>>>>> Materialized,
> >>>>>>>>>>>> Serialized, Joined, Consumed and Produced.
> >>>>>>>>>>>> For that we can make use of the implicit parameters in Scala.
> >>>>>>>>>>>>
> >>>>>>>>>>>> KIP:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> 365%3A+Materialized%2C+Serialized%2C+Joined%2C+Consumed+and+Produced+with+
> >>>>>>>> implicit+Serde
> >>>>>>>>>>>>
> >>>>>>>>>>>> Github PR: https://github.com/apache/kafka/pull/5551
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please make your votes.
> >>>>>>>>>>>> Thanks
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> *Dongjin Lee*
> >>>>>>>>>
> >>>>>>>>> *A hitchhiker in the mathematical world.*
> >>>>>>>>>
> >>>>>>>>> *github:  <http://goog_969573159/>github.com/dongjinleekr
> >>>>>>>>> <http://github.com/dongjinleekr>linkedin: kr.linkedin.com/in/
> >>>>>>>> dongjinleekr
> >>>>>>>>> <http://kr.linkedin.com/in/dongjinleekr>slideshare:
> >>>>>> www.slideshare.net/
> >>>>>>>> dongjinleekr
> >>>>>>>>> <http://www.slideshare.net/dongjinleekr>*
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >
>
>

Re: [VOTE] KIP-366 - Make FunctionConversations private

[Joan Goyeau]

This KIP is now accepted with:
- 3 binding +1
- 2 non binding +1

Thanks all

On Fri, 14 Sep 2018 at 21:05 Matthias J. Sax  wrote:

> +1 (binding)
>
> -Matthias
>
> On 9/14/18 7:55 AM, Damian Guy wrote:
> > +1 (binding)
> >
> > Thanks
> >
> > On Fri, 14 Sep 2018 at 10:00 Joan Goyeau  wrote:
> >
> >> Ok so we have only one binding vote up to now. I guess we need at least
> 3
> >> binding votes.
> >>
> >> Thanks
> >>
> >> On Fri, 14 Sep 2018 at 09:59 Joan Goyeau  wrote:
> >>
> >>> Matt, This is now all updated.
> >>>
> >>> On Fri, 7 Sep 2018 at 03:34 Matthias J. Sax 
> >> wrote:
> >>>
> >>>> Can you please update the KIP accordingly?
> >>>>
> >>>> It still says "make private" instead of "deprecating"
> >>>>
> >>>> -Matthias
> >>>>
> >>>> On 9/6/18 10:07 AM, Attila Sasvári wrote:
> >>>>> +1 (non-binding)
> >>>>>
> >>>>> On Thu, Sep 6, 2018 at 6:38 PM Guozhang Wang 
> >>>> wrote:
> >>>>>
> >>>>>> +1 for deprecating and copying the class over to internals.
> >>>>>>
> >>>>>> On Thu, Sep 6, 2018 at 6:56 AM, Bill Bejeck 
> >> wrote:
> >>>>>>
> >>>>>>> +1
> >>>>>>>
> >>>>>>> -Bill
> >>>>>>>
> >>>>>>> On Thu, Sep 6, 2018 at 4:29 AM Joan Goyeau 
> wrote:
> >>>>>>>
> >>>>>>>> Sournds good, I'll make the deprecation and copy the class over.
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>>
> >>>>>>>> On Wed, 5 Sep 2018 at 22:48 John Roesler 
> >> wrote:
> >>>>>>>>
> >>>>>>>>> I'm a +1 (non-binding) because we doubt the class is in use.
> >>>>>>>>>
> >>>>>>>>> If you decide to copy it to a private version and deprecate the
> >>>>>>> original
> >>>>>>>>> instead, as Matthias suggested, I would still be a +1.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> -John
> >>>>>>>>>
> >>>>>>>>> On Sat, Sep 1, 2018 at 6:47 AM Joan Goyeau 
> >> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> As pointed out in this comment
> >>>>>>>>>> https://github.com/apache/kafka/pull/5539#discussion_r212380648
> >>>>>>> "This
> >>>>>>>>>> class
> >>>>>>>>>> was already defaulted to public visibility, and we can't retract
> >> it
> >>>>>>>> now,
> >>>>>>>>>> without a KIP.", the object FunctionConversions is only of
> >> internal
> >>>>>>> use
> >>>>>>>>> and
> >>>>>>>>>> therefore should be private to the lib only so that we can do
> >>>>>> changes
> >>>>>>>>>> without going through KIP like this one.
> >>>>>>>>>>
> >>>>>>>>>> KIP:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-366%3A+Make+
> >>>>>>> FunctionConversions+private
> >>>>>>>>>>
> >>>>>>>>>> Please make your votes.
> >>>>>>>>>> Thanks
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> -- Guozhang
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >
>
>

Re: [VOTE] KIP-366 - Make FunctionConversations private

[Joan Goyeau]

Ok so we have only one binding vote up to now. I guess we need at least 3
binding votes.

Thanks

On Fri, 14 Sep 2018 at 09:59 Joan Goyeau  wrote:

> Matt, This is now all updated.
>
> On Fri, 7 Sep 2018 at 03:34 Matthias J. Sax  wrote:
>
>> Can you please update the KIP accordingly?
>>
>> It still says "make private" instead of "deprecating"
>>
>> -Matthias
>>
>> On 9/6/18 10:07 AM, Attila Sasvári wrote:
>> > +1 (non-binding)
>> >
>> > On Thu, Sep 6, 2018 at 6:38 PM Guozhang Wang 
>> wrote:
>> >
>> >> +1 for deprecating and copying the class over to internals.
>> >>
>> >> On Thu, Sep 6, 2018 at 6:56 AM, Bill Bejeck  wrote:
>> >>
>> >>> +1
>> >>>
>> >>> -Bill
>> >>>
>> >>> On Thu, Sep 6, 2018 at 4:29 AM Joan Goyeau  wrote:
>> >>>
>> >>>> Sournds good, I'll make the deprecation and copy the class over.
>> >>>>
>> >>>> Thanks
>> >>>>
>> >>>> On Wed, 5 Sep 2018 at 22:48 John Roesler  wrote:
>> >>>>
>> >>>>> I'm a +1 (non-binding) because we doubt the class is in use.
>> >>>>>
>> >>>>> If you decide to copy it to a private version and deprecate the
>> >>> original
>> >>>>> instead, as Matthias suggested, I would still be a +1.
>> >>>>>
>> >>>>> Thanks,
>> >>>>> -John
>> >>>>>
>> >>>>> On Sat, Sep 1, 2018 at 6:47 AM Joan Goyeau  wrote:
>> >>>>>
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>> As pointed out in this comment
>> >>>>>> https://github.com/apache/kafka/pull/5539#discussion_r212380648
>> >>> "This
>> >>>>>> class
>> >>>>>> was already defaulted to public visibility, and we can't retract it
>> >>>> now,
>> >>>>>> without a KIP.", the object FunctionConversions is only of internal
>> >>> use
>> >>>>> and
>> >>>>>> therefore should be private to the lib only so that we can do
>> >> changes
>> >>>>>> without going through KIP like this one.
>> >>>>>>
>> >>>>>> KIP:
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-366%3A+Make+
>> >>> FunctionConversions+private
>> >>>>>>
>> >>>>>> Please make your votes.
>> >>>>>> Thanks
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> -- Guozhang
>> >>
>> >
>>
>>

Re: [VOTE] KIP-366 - Make FunctionConversations private

[Joan Goyeau]

Matt, This is now all updated.

On Fri, 7 Sep 2018 at 03:34 Matthias J. Sax  wrote:

> Can you please update the KIP accordingly?
>
> It still says "make private" instead of "deprecating"
>
> -Matthias
>
> On 9/6/18 10:07 AM, Attila Sasvári wrote:
> > +1 (non-binding)
> >
> > On Thu, Sep 6, 2018 at 6:38 PM Guozhang Wang  wrote:
> >
> >> +1 for deprecating and copying the class over to internals.
> >>
> >> On Thu, Sep 6, 2018 at 6:56 AM, Bill Bejeck  wrote:
> >>
> >>> +1
> >>>
> >>> -Bill
> >>>
> >>> On Thu, Sep 6, 2018 at 4:29 AM Joan Goyeau  wrote:
> >>>
> >>>> Sournds good, I'll make the deprecation and copy the class over.
> >>>>
> >>>> Thanks
> >>>>
> >>>> On Wed, 5 Sep 2018 at 22:48 John Roesler  wrote:
> >>>>
> >>>>> I'm a +1 (non-binding) because we doubt the class is in use.
> >>>>>
> >>>>> If you decide to copy it to a private version and deprecate the
> >>> original
> >>>>> instead, as Matthias suggested, I would still be a +1.
> >>>>>
> >>>>> Thanks,
> >>>>> -John
> >>>>>
> >>>>> On Sat, Sep 1, 2018 at 6:47 AM Joan Goyeau  wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> As pointed out in this comment
> >>>>>> https://github.com/apache/kafka/pull/5539#discussion_r212380648
> >>> "This
> >>>>>> class
> >>>>>> was already defaulted to public visibility, and we can't retract it
> >>>> now,
> >>>>>> without a KIP.", the object FunctionConversions is only of internal
> >>> use
> >>>>> and
> >>>>>> therefore should be private to the lib only so that we can do
> >> changes
> >>>>>> without going through KIP like this one.
> >>>>>>
> >>>>>> KIP:
> >>>>>>
> >>>>>>
> >>>>>
> >>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-366%3A+Make+
> >>> FunctionConversions+private
> >>>>>>
> >>>>>> Please make your votes.
> >>>>>> Thanks
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> -- Guozhang
> >>
> >
>
>

Re: [VOTE] KIP-365: Materialized, Serialized, Joined, Consumed and Produced with implicit Serde

[Joan Goyeau]

Ok so a +1 is non binding by default.

On Tue, 11 Sep 2018 at 17:25 Matthias J. Sax  wrote:

> I only count 3 binding votes (Guozhang, Matthias, Damian). Plus 4
> non-binding (John, Ted, Bill, Dongjin) -- or 5 if you vote your own KIP :)
>
> -Matthias
>
> On 9/11/18 12:53 AM, Joan Goyeau wrote:
> > Ok, so this is now accepted.
> >
> > Binding votes: +5
> > Non-binding votes: +2
> >
> > Thanks
> >
> > On Wed, 5 Sep 2018 at 21:38 John Roesler  wrote:
> >
> >> Hi Joan,
> >>
> >> Damian makes 3 binding votes, and the vote has been open longer than 72
> >> hours, so your KIP vote has passed!
> >>
> >> It's customary for you to send a final reply to this thread stating that
> >> the vote has passed, and stating the number of binding and non-binding
> +1s.
> >>
> >> Also please update the current state to Accepted here:
> >>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-365%3A+Materialized%2C+Serialized%2C+Joined%2C+Consumed+and+Produced+with+implicit+Serde
> >>
> >> And move your kip into the Adopted table here:
> >>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-365%3A+Materialized%2C+Serialized%2C+Joined%2C+Consumed+and+Produced+with+implicit+Serde
> >> (release will be 2.1)
> >>
> >> And finally, move it to Accepted here:
> >> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Streams
> >>
> >> Lastly, you might want to make another pass over the PR and call for
> final
> >> reviews.
> >>
> >> Thanks so much for managing this process,
> >> -John
> >>
> >> On Mon, Sep 3, 2018 at 11:00 AM Damian Guy 
> wrote:
> >>
> >>> +1
> >>>
> >>> On Sun, 2 Sep 2018 at 15:20 Matthias J. Sax 
> >> wrote:
> >>>
> >>>> +1 (binding)
> >>>>
> >>>> On 9/1/18 2:40 PM, Guozhang Wang wrote:
> >>>>> +1 (binding).
> >>>>>
> >>>>> On Mon, Aug 27, 2018 at 5:20 PM, Dongjin Lee 
> >>> wrote:
> >>>>>
> >>>>>> +1 (non-binding)
> >>>>>>
> >>>>>> On Tue, Aug 28, 2018 at 8:53 AM Bill Bejeck 
> >>> wrote:
> >>>>>>
> >>>>>>> +1
> >>>>>>>
> >>>>>>> -Bill
> >>>>>>>
> >>>>>>> On Mon, Aug 27, 2018 at 3:24 PM Ted Yu 
> >> wrote:
> >>>>>>>
> >>>>>>>> +1
> >>>>>>>>
> >>>>>>>> On Mon, Aug 27, 2018 at 12:18 PM John Roesler 
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> +1 (non-binding)
> >>>>>>>>>
> >>>>>>>>> On Sat, Aug 25, 2018 at 1:16 PM Joan Goyeau 
> >>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> We want to make sure that we always have a serde for all
> >>>>>>> Materialized,
> >>>>>>>>>> Serialized, Joined, Consumed and Produced.
> >>>>>>>>>> For that we can make use of the implicit parameters in Scala.
> >>>>>>>>>>
> >>>>>>>>>> KIP:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> >>>>>>
> >>>>
> >>>
> >>
> 365%3A+Materialized%2C+Serialized%2C+Joined%2C+Consumed+and+Produced+with+
> >>>>>> implicit+Serde
> >>>>>>>>>>
> >>>>>>>>>> Github PR: https://github.com/apache/kafka/pull/5551
> >>>>>>>>>>
> >>>>>>>>>> Please make your votes.
> >>>>>>>>>> Thanks
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> *Dongjin Lee*
> >>>>>>>
> >>>>>>> *A hitchhiker in the mathematical world.*
> >>>>>>>
> >>>>>>> *github:  <http://goog_969573159/>github.com/dongjinleekr
> >>>>>>> <http://github.com/dongjinleekr>linkedin: kr.linkedin.com/in/
> >>>>>> dongjinleekr
> >>>>>>> <http://kr.linkedin.com/in/dongjinleekr>slideshare:
> >>>> www.slideshare.net/
> >>>>>> dongjinleekr
> >>>>>>> <http://www.slideshare.net/dongjinleekr>*
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>

[jira] [Created] (KAFKA-7396) KIP-365: Materialized, Serialized, Joined, Consumed and Produced with implicit Serde

[Joan Goyeau (JIRA)]

Joan Goyeau created KAFKA-7396:
--

 Summary: KIP-365: Materialized, Serialized, Joined, Consumed and 
Produced with implicit Serde
 Key: KAFKA-7396
 URL: https://issues.apache.org/jira/browse/KAFKA-7396
 Project: Kafka
  Issue Type: Improvement
  Components: streams
Reporter: Joan Goyeau
 Fix For: 2.1.0


See KIP: 
https://cwiki.apache.org/confluence/display/KAFKA/KIP-365%3A+Materialized%2C+Serialized%2C+Joined%2C+Consumed+and+Produced+with+implicit+Serde



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] KIP-365: Materialized, Serialized, Joined, Consumed and Produced with implicit Serde

[Joan Goyeau]

Ok, so this is now accepted.

Binding votes: +5
Non-binding votes: +2

Thanks

On Wed, 5 Sep 2018 at 21:38 John Roesler  wrote:

> Hi Joan,
>
> Damian makes 3 binding votes, and the vote has been open longer than 72
> hours, so your KIP vote has passed!
>
> It's customary for you to send a final reply to this thread stating that
> the vote has passed, and stating the number of binding and non-binding +1s.
>
> Also please update the current state to Accepted here:
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-365%3A+Materialized%2C+Serialized%2C+Joined%2C+Consumed+and+Produced+with+implicit+Serde
>
> And move your kip into the Adopted table here:
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-365%3A+Materialized%2C+Serialized%2C+Joined%2C+Consumed+and+Produced+with+implicit+Serde
> (release will be 2.1)
>
> And finally, move it to Accepted here:
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Streams
>
> Lastly, you might want to make another pass over the PR and call for final
> reviews.
>
> Thanks so much for managing this process,
> -John
>
> On Mon, Sep 3, 2018 at 11:00 AM Damian Guy  wrote:
>
> > +1
> >
> > On Sun, 2 Sep 2018 at 15:20 Matthias J. Sax 
> wrote:
> >
> > > +1 (binding)
> > >
> > > On 9/1/18 2:40 PM, Guozhang Wang wrote:
> > > > +1 (binding).
> > > >
> > > > On Mon, Aug 27, 2018 at 5:20 PM, Dongjin Lee 
> > wrote:
> > > >
> > > >> +1 (non-binding)
> > > >>
> > > >> On Tue, Aug 28, 2018 at 8:53 AM Bill Bejeck 
> > wrote:
> > > >>
> > > >>> +1
> > > >>>
> > > >>> -Bill
> > > >>>
> > > >>> On Mon, Aug 27, 2018 at 3:24 PM Ted Yu 
> wrote:
> > > >>>
> > > >>>> +1
> > > >>>>
> > > >>>> On Mon, Aug 27, 2018 at 12:18 PM John Roesler 
> > > >> wrote:
> > > >>>>
> > > >>>>> +1 (non-binding)
> > > >>>>>
> > > >>>>> On Sat, Aug 25, 2018 at 1:16 PM Joan Goyeau 
> > wrote:
> > > >>>>>
> > > >>>>>> Hi,
> > > >>>>>>
> > > >>>>>> We want to make sure that we always have a serde for all
> > > >>> Materialized,
> > > >>>>>> Serialized, Joined, Consumed and Produced.
> > > >>>>>> For that we can make use of the implicit parameters in Scala.
> > > >>>>>>
> > > >>>>>> KIP:
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > >>
> > >
> >
> 365%3A+Materialized%2C+Serialized%2C+Joined%2C+Consumed+and+Produced+with+
> > > >> implicit+Serde
> > > >>>>>>
> > > >>>>>> Github PR: https://github.com/apache/kafka/pull/5551
> > > >>>>>>
> > > >>>>>> Please make your votes.
> > > >>>>>> Thanks
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>> --
> > > >>> *Dongjin Lee*
> > > >>>
> > > >>> *A hitchhiker in the mathematical world.*
> > > >>>
> > > >>> *github:  <http://goog_969573159/>github.com/dongjinleekr
> > > >>> <http://github.com/dongjinleekr>linkedin: kr.linkedin.com/in/
> > > >> dongjinleekr
> > > >>> <http://kr.linkedin.com/in/dongjinleekr>slideshare:
> > > www.slideshare.net/
> > > >> dongjinleekr
> > > >>> <http://www.slideshare.net/dongjinleekr>*
> > > >>>
> > > >>
> > > >
> > > >
> > > >
> > >
> > >
> >
>

Re: [VOTE] KIP-366 - Make FunctionConversations private

[Joan Goyeau]

Sournds good, I'll make the deprecation and copy the class over.

Thanks

On Wed, 5 Sep 2018 at 22:48 John Roesler  wrote:

> I'm a +1 (non-binding) because we doubt the class is in use.
>
> If you decide to copy it to a private version and deprecate the original
> instead, as Matthias suggested, I would still be a +1.
>
> Thanks,
> -John
>
> On Sat, Sep 1, 2018 at 6:47 AM Joan Goyeau  wrote:
>
> > Hi,
> >
> > As pointed out in this comment
> > https://github.com/apache/kafka/pull/5539#discussion_r212380648 "This
> > class
> > was already defaulted to public visibility, and we can't retract it now,
> > without a KIP.", the object FunctionConversions is only of internal use
> and
> > therefore should be private to the lib only so that we can do changes
> > without going through KIP like this one.
> >
> > KIP:
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-366%3A+Make+FunctionConversions+private
> >
> > Please make your votes.
> > Thanks
> >
>

[VOTE] KIP-366 - Make FunctionConversations private

[Joan Goyeau]

Hi,

As pointed out in this comment
https://github.com/apache/kafka/pull/5539#discussion_r212380648 "This class
was already defaulted to public visibility, and we can't retract it now,
without a KIP.", the object FunctionConversions is only of internal use and
therefore should be private to the lib only so that we can do changes
without going through KIP like this one.

KIP:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-366%3A+Make+FunctionConversions+private

Please make your votes.
Thanks

Re: [VOTE] KIP-363: Make FunctionConversions private

[Joan Goyeau]

Ah ok I didn't know we need multiple binding vote.
Should I send again a new email with the updated KIP-366 title?

Thanks

On Wed, 29 Aug 2018 at 21:14 John Roesler  wrote:

> Hey Joan,
>
> It looks like you've updated the KIP to "Accepted", but I only count one
> binding vote (Guozhang). Ted, Attila, Bill, and myself are all non-binding
> votes.
>
> For reference, these are all folks who hold binding votes:
> https://kafka.apache.org/committers . Obviously, they don't all take note
> of every KIP, so we sometimes have to keep pinging the thread with
> reminders that we are waiting on binding votes.
>
> Also, people muddied the water by responding "+1" to this thread, but it's
> customary to start a new thread entitled "[VOTE] KIP-366: Make
> FunctionConversions private" to let people know when the voting has
> actually started.
>
> Thanks,
> -John
>
> On Mon, Aug 27, 2018 at 3:44 PM Joan Goyeau  wrote:
>
> > John, no this is for internal use only.
> > I fact I expect this object to go away with the drop of Scala 2.11 since
> in
> > Scala 2.12 we have support for SAM.
> >
> > Thanks
> >
> > On Mon, 27 Aug 2018 at 15:41 John Roesler  wrote:
> >
> > > Hey Joan,
> > >
> > > I was thinking more about this... Do any of the conversions in
> > > FunctionConversions convert to types that are used in the public Scala
> > > interface?
> > >
> > > If you've already checked, then carry on.
> > >
> > > Otherwise, we should leave public any that might be in use.
> > >
> > > Thanks,
> > > -John
> > >
> > > On Sat, Aug 25, 2018 at 12:19 PM Joan Goyeau  wrote:
> > >
> > > > Thanks Attila, it's done.
> > > >
> > > > On Sat, 25 Aug 2018 at 02:57 Ted Yu  wrote:
> > > >
> > > > > +1
> > > > >
> > > > > On Fri, Aug 24, 2018 at 5:17 PM Attila Sasvári <
> asasv...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Hi there,
> > > > > >
> > > > > > There is a conflicting KIP with the same number, see
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-363%3A+Allow+performance+tools+to+print+final+results+to+output+file
> > > > > >
> > > > > > Its discussion was started earlier, on August 23
> > > > > > https://www.mail-archive.com/dev@kafka.apache.org/msg91132.html
> > and
> > > > KIP
> > > > > > page already includes it:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals
> > > > > >
> > > > > > Please update KIP number to resolve the conflict.
> > > > > >
> > > > > > Apart from this, +1 (non-binding) and thanks for the KIP!
> > > > > >
> > > > > > Regards,
> > > > > > - Attila
> > > > > >
> > > > > >
> > > > > > Guozhang Wang  (időpont: 2018. aug. 24., P,
> > > 20:26)
> > > > > ezt
> > > > > > írta:
> > > > > >
> > > > > > > +1 from me (binding).
> > > > > > >
> > > > > > > On Fri, Aug 24, 2018 at 11:24 AM, Joan Goyeau  >
> > > > wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > As pointed out in this comment #5539 (comment)
> > > > > > > > <
> > https://github.com/apache/kafka/pull/5539#discussion_r212380648
> > > >
> > > > > > "This
> > > > > > > > class was already defaulted to public visibility, and we
> can't
> > > > > retract
> > > > > > it
> > > > > > > > now, without a KIP.", the object FunctionConversions is only
> of
> > > > > > internal
> > > > > > > > use and therefore should be private to the lib only so that
> we
> > > can
> > > > do
> > > > > > > > changes without going through KIP like this one.
> > > > > > > >
> > > > > > > > Please make your vote

Re: [VOTE] KIP-363: Make FunctionConversions private

[Joan Goyeau]

John, no this is for internal use only.
I fact I expect this object to go away with the drop of Scala 2.11 since in
Scala 2.12 we have support for SAM.

Thanks

On Mon, 27 Aug 2018 at 15:41 John Roesler  wrote:

> Hey Joan,
>
> I was thinking more about this... Do any of the conversions in
> FunctionConversions convert to types that are used in the public Scala
> interface?
>
> If you've already checked, then carry on.
>
> Otherwise, we should leave public any that might be in use.
>
> Thanks,
> -John
>
> On Sat, Aug 25, 2018 at 12:19 PM Joan Goyeau  wrote:
>
> > Thanks Attila, it's done.
> >
> > On Sat, 25 Aug 2018 at 02:57 Ted Yu  wrote:
> >
> > > +1
> > >
> > > On Fri, Aug 24, 2018 at 5:17 PM Attila Sasvári 
> > > wrote:
> > >
> > > > Hi there,
> > > >
> > > > There is a conflicting KIP with the same number, see
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-363%3A+Allow+performance+tools+to+print+final+results+to+output+file
> > > >
> > > > Its discussion was started earlier, on August 23
> > > > https://www.mail-archive.com/dev@kafka.apache.org/msg91132.html and
> > KIP
> > > > page already includes it:
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals
> > > >
> > > > Please update KIP number to resolve the conflict.
> > > >
> > > > Apart from this, +1 (non-binding) and thanks for the KIP!
> > > >
> > > > Regards,
> > > > - Attila
> > > >
> > > >
> > > > Guozhang Wang  (időpont: 2018. aug. 24., P,
> 20:26)
> > > ezt
> > > > írta:
> > > >
> > > > > +1 from me (binding).
> > > > >
> > > > > On Fri, Aug 24, 2018 at 11:24 AM, Joan Goyeau 
> > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > As pointed out in this comment #5539 (comment)
> > > > > > <https://github.com/apache/kafka/pull/5539#discussion_r212380648
> >
> > > > "This
> > > > > > class was already defaulted to public visibility, and we can't
> > > retract
> > > > it
> > > > > > now, without a KIP.", the object FunctionConversions is only of
> > > > internal
> > > > > > use and therefore should be private to the lib only so that we
> can
> > do
> > > > > > changes without going through KIP like this one.
> > > > > >
> > > > > > Please make your vote.
> > > > > >
> > > > > > On Fri, 24 Aug 2018 at 19:14 John Roesler 
> > wrote:
> > > > > >
> > > > > > > I'm also in favor of this. I don't think it's controversial
> > either.
> > > > > > Should
> > > > > > > we just move to a vote?
> > > > > > >
> > > > > > > On Thu, Aug 23, 2018 at 7:01 PM Guozhang Wang <
> > wangg...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > +1.
> > > > > > > >
> > > > > > > > On Thu, Aug 23, 2018 at 12:47 PM, Ted Yu <
> yuzhih...@gmail.com>
> > > > > wrote:
> > > > > > > >
> > > > > > > > > +1
> > > > > > > > >
> > > > > > > > > In the Motivation section, you can quote the comment from
> > pull
> > > > > > request
> > > > > > > so
> > > > > > > > > that reader doesn't have to click through.
> > > > > > > > >
> > > > > > > > > Cheers
> > > > > > > > >
> > > > > > > > > On Thu, Aug 23, 2018 at 12:13 PM Joan Goyeau <
> > j...@goyeau.com>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > As pointed out in this comment #5539 (comment)
> > > > > > > > > > <
> > > > https://github.com/apache/kafka/pull/5539#discussion_r212380648
> > > > > >
> > > > > > > the
> > > > > > > > > > object FunctionConversions is only of internal use and
> > > > therefore
> > > > > > > should
> > > > > > > > > be
> > > > > > > > > > private to the lib only so that we can do changes without
> > > going
> > > > > > > through
> > > > > > > > > KIP
> > > > > > > > > > like this one.
> > > > > > > > > >
> > > > > > > > > > KIP:
> > > > > > > > > >
> > > > > > > > > >
> > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-363%3A+Make+
> > > > > > > > > FunctionConversions+private
> > > > > > > > > >
> > > > > > > > > > Thanks
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > -- Guozhang
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > -- Guozhang
> > > > >
> > > >
> > >
> >
>

[VOTE] KIP-365: Materialized, Serialized, Joined, Consumed and Produced with implicit Serde

[Joan Goyeau]

Hi,

We want to make sure that we always have a serde for all Materialized,
Serialized, Joined, Consumed and Produced.
For that we can make use of the implicit parameters in Scala.

KIP:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-365%3A+Materialized%2C+Serialized%2C+Joined%2C+Consumed+and+Produced+with+implicit+Serde

Github PR: https://github.com/apache/kafka/pull/5551

Please make your votes.
Thanks

Re: [VOTE] KIP-363: Make FunctionConversions private

[Joan Goyeau]

Thanks Attila, it's done.

On Sat, 25 Aug 2018 at 02:57 Ted Yu  wrote:

> +1
>
> On Fri, Aug 24, 2018 at 5:17 PM Attila Sasvári 
> wrote:
>
> > Hi there,
> >
> > There is a conflicting KIP with the same number, see
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-363%3A+Allow+performance+tools+to+print+final+results+to+output+file
> >
> > Its discussion was started earlier, on August 23
> > https://www.mail-archive.com/dev@kafka.apache.org/msg91132.html and KIP
> > page already includes it:
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals
> >
> > Please update KIP number to resolve the conflict.
> >
> > Apart from this, +1 (non-binding) and thanks for the KIP!
> >
> > Regards,
> > - Attila
> >
> >
> > Guozhang Wang  (időpont: 2018. aug. 24., P, 20:26)
> ezt
> > írta:
> >
> > > +1 from me (binding).
> > >
> > > On Fri, Aug 24, 2018 at 11:24 AM, Joan Goyeau  wrote:
> > >
> > > > Hi,
> > > >
> > > > As pointed out in this comment #5539 (comment)
> > > > <https://github.com/apache/kafka/pull/5539#discussion_r212380648>
> > "This
> > > > class was already defaulted to public visibility, and we can't
> retract
> > it
> > > > now, without a KIP.", the object FunctionConversions is only of
> > internal
> > > > use and therefore should be private to the lib only so that we can do
> > > > changes without going through KIP like this one.
> > > >
> > > > Please make your vote.
> > > >
> > > > On Fri, 24 Aug 2018 at 19:14 John Roesler  wrote:
> > > >
> > > > > I'm also in favor of this. I don't think it's controversial either.
> > > > Should
> > > > > we just move to a vote?
> > > > >
> > > > > On Thu, Aug 23, 2018 at 7:01 PM Guozhang Wang 
> > > > wrote:
> > > > >
> > > > > > +1.
> > > > > >
> > > > > > On Thu, Aug 23, 2018 at 12:47 PM, Ted Yu 
> > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > In the Motivation section, you can quote the comment from pull
> > > > request
> > > > > so
> > > > > > > that reader doesn't have to click through.
> > > > > > >
> > > > > > > Cheers
> > > > > > >
> > > > > > > On Thu, Aug 23, 2018 at 12:13 PM Joan Goyeau 
> > > > wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > As pointed out in this comment #5539 (comment)
> > > > > > > > <
> > https://github.com/apache/kafka/pull/5539#discussion_r212380648
> > > >
> > > > > the
> > > > > > > > object FunctionConversions is only of internal use and
> > therefore
> > > > > should
> > > > > > > be
> > > > > > > > private to the lib only so that we can do changes without
> going
> > > > > through
> > > > > > > KIP
> > > > > > > > like this one.
> > > > > > > >
> > > > > > > > KIP:
> > > > > > > >
> > > > > > > >
> > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-363%3A+Make+
> > > > > > > FunctionConversions+private
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > -- Guozhang
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > -- Guozhang
> > >
> >
>

[VOTE] KIP-363: Make FunctionConversions private

[Joan Goyeau]

Hi,

As pointed out in this comment #5539 (comment)
<https://github.com/apache/kafka/pull/5539#discussion_r212380648> "This
class was already defaulted to public visibility, and we can't retract it
now, without a KIP.", the object FunctionConversions is only of internal
use and therefore should be private to the lib only so that we can do
changes without going through KIP like this one.

Please make your vote.

On Fri, 24 Aug 2018 at 19:14 John Roesler  wrote:

> I'm also in favor of this. I don't think it's controversial either. Should
> we just move to a vote?
>
> On Thu, Aug 23, 2018 at 7:01 PM Guozhang Wang  wrote:
>
> > +1.
> >
> > On Thu, Aug 23, 2018 at 12:47 PM, Ted Yu  wrote:
> >
> > > +1
> > >
> > > In the Motivation section, you can quote the comment from pull request
> so
> > > that reader doesn't have to click through.
> > >
> > > Cheers
> > >
> > > On Thu, Aug 23, 2018 at 12:13 PM Joan Goyeau  wrote:
> > >
> > > > Hi,
> > > >
> > > > As pointed out in this comment #5539 (comment)
> > > > <https://github.com/apache/kafka/pull/5539#discussion_r212380648>
> the
> > > > object FunctionConversions is only of internal use and therefore
> should
> > > be
> > > > private to the lib only so that we can do changes without going
> through
> > > KIP
> > > > like this one.
> > > >
> > > > KIP:
> > > >
> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-363%3A+Make+
> > > FunctionConversions+private
> > > >
> > > > Thanks
> > > >
> > >
> >
> >
> >
> > --
> > -- Guozhang
> >
>

Re: Build failed in Jenkins: kafka-trunk-jdk10 #429

[Joan Goyeau]

Yeah it's was all good in the end :)

Thanks Ted

On Thu, 23 Aug 2018 at 21:42 Ted Yu  wrote:

> I ran streams unit tests as of
> commit 4156ea0a9bcca67d209fd3b43d2268c9abd5a0b5 .
>
> All tests passed locally.
>
> FYI
>
> On Thu, Aug 23, 2018 at 12:23 PM Joan Goyeau  wrote:
>
> > I'm looking into this one.
> >
> > On Thu, 23 Aug 2018 at 20:19 Apache Jenkins Server <
> > jenk...@builds.apache.org> wrote:
> >
> > > See <
> > >
> >
> https://builds.apache.org/job/kafka-trunk-jdk10/429/display/redirect?page=changes
> > > >
> > >
> > > Changes:
> > >
> > > [wangguoz] KAFKA-7316: Fix Streams Scala filter recursive call #5538
> > >
> > > --
> > > [...truncated 1.98 MB...]
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > > shouldNotHaveSameAssignmentOnAnyTwoHosts PASSED
> > >
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > > shouldRebalanceTasksToClientsBasedOnCapacity STARTED
> > >
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > > shouldRebalanceTasksToClientsBasedOnCapacity PASSED
> > >
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > >
> > shouldNotHaveSameAssignmentOnAnyTwoHostsWhenThereArePreviousStandbyTasks
> > > STARTED
> > >
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > >
> > shouldNotHaveSameAssignmentOnAnyTwoHostsWhenThereArePreviousStandbyTasks
> > > PASSED
> > >
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > >
> > >
> >
> shouldNotAssignStandbyTaskReplicasWhenNoClientAvailableWithoutHavingTheTaskAssigned
> > > STARTED
> > >
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > >
> > >
> >
> shouldNotAssignStandbyTaskReplicasWhenNoClientAvailableWithoutHavingTheTaskAssigned
> > > PASSED
> > >
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > > shouldAssignEachActiveTaskToOneClientWhenMoreClientsThanTasks STARTED
> > >
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > > shouldAssignEachActiveTaskToOneClientWhenMoreClientsThanTasks PASSED
> > >
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > > shouldAssignTopicGroupIdEvenlyAcrossClientsWithStandByTasks STARTED
> > >
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > > shouldAssignTopicGroupIdEvenlyAcrossClientsWithStandByTasks PASSED
> > >
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > > shouldAssignTasksNotPreviouslyActiveToNewClient STARTED
> > >
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > > shouldAssignTasksNotPreviouslyActiveToNewClient PASSED
> > >
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > > shouldAssignOneActiveTaskToEachProcessWhenTaskCountSameAsProcessCount
> > > STARTED
> > >
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > > shouldAssignOneActiveTaskToEachProcessWhenTaskCountSameAsProcessCount
> > > PASSED
> > >
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > > shouldReBalanceTasksAcrossClientsWhenCapacityLessThanTaskCount
> STARTED
> > >
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > > shouldReBalanceTasksAcrossClientsWhenCapacityLessThanTaskCount PASSED
> > >
> > >
> >
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > > > shouldBalanceActiveAndStandbyTasksAcrossAvailableClients STARTED
> > >
> > >
> >
>

Re: Build failed in Jenkins: kafka-trunk-jdk10 #429

[Joan Goyeau]

I'm looking into this one.

On Thu, 23 Aug 2018 at 20:19 Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://builds.apache.org/job/kafka-trunk-jdk10/429/display/redirect?page=changes
> >
>
> Changes:
>
> [wangguoz] KAFKA-7316: Fix Streams Scala filter recursive call #5538
>
> --
> [...truncated 1.98 MB...]
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldNotHaveSameAssignmentOnAnyTwoHosts PASSED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldRebalanceTasksToClientsBasedOnCapacity STARTED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldRebalanceTasksToClientsBasedOnCapacity PASSED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldNotHaveSameAssignmentOnAnyTwoHostsWhenThereArePreviousStandbyTasks
> STARTED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldNotHaveSameAssignmentOnAnyTwoHostsWhenThereArePreviousStandbyTasks
> PASSED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> >
> shouldNotAssignStandbyTaskReplicasWhenNoClientAvailableWithoutHavingTheTaskAssigned
> STARTED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> >
> shouldNotAssignStandbyTaskReplicasWhenNoClientAvailableWithoutHavingTheTaskAssigned
> PASSED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldAssignEachActiveTaskToOneClientWhenMoreClientsThanTasks STARTED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldAssignEachActiveTaskToOneClientWhenMoreClientsThanTasks PASSED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldAssignTopicGroupIdEvenlyAcrossClientsWithStandByTasks STARTED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldAssignTopicGroupIdEvenlyAcrossClientsWithStandByTasks PASSED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldAssignTasksNotPreviouslyActiveToNewClient STARTED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldAssignTasksNotPreviouslyActiveToNewClient PASSED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldAssignOneActiveTaskToEachProcessWhenTaskCountSameAsProcessCount
> STARTED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldAssignOneActiveTaskToEachProcessWhenTaskCountSameAsProcessCount
> PASSED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldReBalanceTasksAcrossClientsWhenCapacityLessThanTaskCount STARTED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldReBalanceTasksAcrossClientsWhenCapacityLessThanTaskCount PASSED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldBalanceActiveAndStandbyTasksAcrossAvailableClients STARTED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldBalanceActiveAndStandbyTasksAcrossAvailableClients PASSED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldAssignActiveAndStandbyTasks STARTED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldAssignActiveAndStandbyTasks PASSED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldNotHaveSameAssignmentOnAnyTwoHostsWhenThereArePreviousActiveTasks
> STARTED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldNotHaveSameAssignmentOnAnyTwoHostsWhenThereArePreviousActiveTasks
> PASSED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldAssignTasksToClientWithPreviousStandbyTasks STARTED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldAssignTasksToClientWithPreviousStandbyTasks PASSED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldReBalanceTasksAcrossAllClientsWhenCapacityAndTaskCountTheSame
> STARTED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldReBalanceTasksAcrossAllClientsWhenCapacityAndTaskCountTheSame PASSED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldAssignMoreTasksToClientWithMoreCapacity STARTED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldAssignMoreTasksToClientWithMoreCapacity PASSED
>
> org.apache.kafka.streams.processor.internals.assignment.StickyTaskAssignorTest
> > shouldMigrateActiveTasksToNewProcessWithoutChangingAllAssignments STARTED

[DISCUSS] KIP-363: Make FunctionConversions private

[Joan Goyeau]

Hi,

As pointed out in this comment #5539 (comment)
 the
object FunctionConversions is only of internal use and therefore should be
private to the lib only so that we can do changes without going through KIP
like this one.

KIP:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-363%3A+Make+FunctionConversions+private

Thanks

Re: Use of a formatter like Scalafmt

[Joan Goyeau]

Thanks guys for your feedback.

Matthias, we can change the config to use JavaDoc (1 space) instead of the
Scala doc (2 space), that would limit the change indeed.

When I say we can apply this change module by module I mean we can specify
folders, so we could breakdown core too.

I updated the PR to include only the streams folder and the JavaDoc change,
see:
https://github.com/apache/kafka/pull/4965

That would be a good start, see how it goes and later move on to some other
modules.
Let me know your thoughts on the PR too about rewritings that you don't
like or like.

Thanks


On Thu, 10 May 2018, 05:18 Jeff Widman, <j...@jeffwidman.com> wrote:

> It certainly annoys me every time I open the code and my linter starts
> highlighting that some code is indented with spaces and some with tabs...
> increasing consistency across the codebase would be appreciated.
>
> On Wed, May 9, 2018 at 9:10 PM, Ismael Juma <ism...@juma.me.uk> wrote:
>
> > Sounds good about doing this for Kafka streams scala first. Core is a bit
> > more complicated so may require more discussion.
> >
> > Ismael
> >
> > On Wed, 9 May 2018, 16:59 Matthias J. Sax, <matth...@confluent.io>
> wrote:
> >
> > > Joan,
> > >
> > > thanks for starting this initiative. I am overall +1
> > >
> > > However, I am worried about applying it to `core` module as the change
> > > is massive. For the Kafka Streams Scala module, that is new and was not
> > > released yet, I am +1.
> > >
> > > A personal thing about the style: the 2-space indention for JavaDocs is
> > > a little weird.
> > >
> > > /**
> > >  *
> > >  */
> > >
> > > is changed to
> > >
> > > /**
> > >   *
> > >   */
> > >
> > > Not sure if this can be fixed easily in the style file? If not, I am
> > > also fine with the change.
> > >
> > > This change also affect the license headers of many files and exposing
> > > that those use the wrong comment format anyway. They should use regular
> > > comments
> > >
> > > /*
> > >  *
> > >  */
> > >
> > > but not JavaDoc comments
> > >
> > > /**
> > >  *
> > >  */
> > >
> > > (We fixed this for Java source code in the past already -- maybe it's
> > > time to fix it for Scala code base, too.
> > >
> > >
> > >
> > > -Matthias
> > >
> > > On 5/9/18 4:45 PM, Joan Goyeau wrote:
> > > > Hi Ted,
> > > >
> > > > As far as I understand this is an issue for PRs and back porting the
> > > > changes to other branches.
> > > >
> > > > Applying the tool to the other branches should also resolve the
> > conflicts
> > > > as the formattings will match, leaving only the actual changes in the
> > > diffs.
> > > > That's what we did sometime ago at my work and it went quiet
> smoothly.
> > > >
> > > > If we don't want to do a big bang commit then I'm thinking we might
> > want
> > > to
> > > > make it gradually by applying it module by module?
> > > > This is one idea do you have any other?
> > > >
> > > > I know formatting sounds like the useless thing that doesn't matter
> > and I
> > > > totally agree with this, that's why I don't want to care about it
> while
> > > > coding.
> > > >
> > > > Thanks
> > > >
> > > > On Thu, 10 May 2018 at 00:15 Ted Yu <yuzhih...@gmail.com> wrote:
> > > >
> > > >> Applying the tool across code base would result in massive changes.
> > > >> How would this be handled ?
> > > >>  Original message From: Joan Goyeau <
> j...@goyeau.com>
> > > >> Date: 5/9/18  3:31 PM  (GMT-08:00) To: dev@kafka.apache.org
> Subject:
> > > Use
> > > >> of a formatter like Scalafmt
> > > >> Hi,
> > > >>
> > > >> Contributing to Kafka Streams' Scala API, I've been kinda lost on
> how
> > > >> should I format my code.
> > > >> I know formatting is the start of religion wars but personally I
> have
> > no
> > > >> preference at all. I just want consistency across the codebase, no
> > > >> unnecessary formatting diffs in PRs and offload the formatting to a
> > tool
> > > >> that will do it for me and concentrate on what matters (not
> > formatting).
> > > >>
> > > >> So I opened the following PR where I put arbitrary rules in
> > > .scalafmt.conf
> > > >> <
> > > >>
> > > https://github.com/apache/kafka/pull/4965/files#diff-
> > 8af3e1355c23c331ee2b848e12c5219f
> > > >>>
> > > >> :
> > > >> https://github.com/apache/kafka/pull/4965
> > > >>
> > > >> Please let me know what do you think and if we can move this forward
> > and
> > > >> settle something.
> > > >>
> > > >> Thanks
> > > >>
> > > >
> > >
> > >
> >
>
>
>
> --
>
> *Jeff Widman*
> jeffwidman.com <http://www.jeffwidman.com/> | 740-WIDMAN-J (943-6265)
> <><
>

Re: Use of a formatter like Scalafmt

[Joan Goyeau]

Hi Ted,

As far as I understand this is an issue for PRs and back porting the
changes to other branches.

Applying the tool to the other branches should also resolve the conflicts
as the formattings will match, leaving only the actual changes in the diffs.
That's what we did sometime ago at my work and it went quiet smoothly.

If we don't want to do a big bang commit then I'm thinking we might want to
make it gradually by applying it module by module?
This is one idea do you have any other?

I know formatting sounds like the useless thing that doesn't matter and I
totally agree with this, that's why I don't want to care about it while
coding.

Thanks

On Thu, 10 May 2018 at 00:15 Ted Yu <yuzhih...@gmail.com> wrote:

> Applying the tool across code base would result in massive changes.
> How would this be handled ?
>  Original message ----From: Joan Goyeau <j...@goyeau.com>
> Date: 5/9/18  3:31 PM  (GMT-08:00) To: dev@kafka.apache.org Subject: Use
> of a formatter like Scalafmt
> Hi,
>
> Contributing to Kafka Streams' Scala API, I've been kinda lost on how
> should I format my code.
> I know formatting is the start of religion wars but personally I have no
> preference at all. I just want consistency across the codebase, no
> unnecessary formatting diffs in PRs and offload the formatting to a tool
> that will do it for me and concentrate on what matters (not formatting).
>
> So I opened the following PR where I put arbitrary rules in .scalafmt.conf
> <
> https://github.com/apache/kafka/pull/4965/files#diff-8af3e1355c23c331ee2b848e12c5219f
> >
> :
> https://github.com/apache/kafka/pull/4965
>
> Please let me know what do you think and if we can move this forward and
> settle something.
>
> Thanks
>

Use of a formatter like Scalafmt

[Joan Goyeau]

Hi,

Contributing to Kafka Streams' Scala API, I've been kinda lost on how
should I format my code.
I know formatting is the start of religion wars but personally I have no
preference at all. I just want consistency across the codebase, no
unnecessary formatting diffs in PRs and offload the formatting to a tool
that will do it for me and concentrate on what matters (not formatting).

So I opened the following PR where I put arbitrary rules in .scalafmt.conf

:
https://github.com/apache/kafka/pull/4965

Please let me know what do you think and if we can move this forward and
settle something.

Thanks