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

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

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

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

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

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 acc

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

t; +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 > >

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

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,

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

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

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

gt; > > >>> > > > >>> -Bill > > > >>> > > > >>> On Mon, Aug 27, 2018 at 3:24 PM Ted Yu > wrote: > > > >>> > > > >>>> +1 > > > >>>> > > > >>>> On

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

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

[VOTE] KIP-366 - Make FunctionConversations private

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

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

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

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

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

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

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

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

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

[VOTE] KIP-363: Make FunctionConversions private

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

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

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

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

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 >

[DISCUSS] KIP-363: Make FunctionConversions private

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

Re: Use of a formatter like Scalafmt

t; that those use the wrong comment format anyway. They should use regular > > > comments > > > > > > /* > > > * > > > */ > > > > > > but not JavaDoc comments > > > > > > /** > > > * > > > */ >

Re: Use of a formatter like Scalafmt

ally 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 wrote: > Applying the tool across code base would result in massive changes. > How would this be handled ? > ---- Original message From: Joan Goye

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 formatt