I am closing this vote. The KIP is accepted with 3 non-binding (Ted, Bill, Satish) and 3 binding (Guozhang, Damian, Matthias) votes.
Thanks a lot for the discussion and voting. -Matthias On 1/16/18 10:08 AM, Matthias J. Sax wrote: > ATM, StreamsConfig is immutable. Thus, it's just boiler plate code for > the user. > > If we really add a builder pattern or change StreamsConfig, we can > update the API accordingly. We will need a KIP for those changes anyway. > But for now, it seems to be best to avoid boiler plate if possible. > > Just my 2 cents. > > -Matthias > > On 1/16/18 9:59 AM, Colin McCabe wrote: >> Why not just have a StreamsConfig constructor that takes a Properties >> object? This has a few advantages. Firstly, because it's purely additive, >> it doesn't create any deprecated functions or compatibility issues that we >> have to clean up later. Secondly, if we decide to do something interesting >> with StreamsConfig later, we still have it. For example, we could have a >> builder, or some interesting ways to serialize it or send it to a string. >> >> best, >> Colin >> >> >> On Tue, Jan 16, 2018, at 09:54, Matthias J. Sax wrote: >>> Thanks for updating the KIP. >>> >>> I am recasting my vote +1 (binding). >>> >>> >>> -Matthias >>> >>> On 1/13/18 4:30 AM, Boyang Chen wrote: >>>> Hey Matt and Guozhang, >>>> >>>> >>>> I have already updated the pull >>>> request: https://github.com/apache/kafka/pull/4354 >>>> >>>> and the >>>> KIP: >>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-245%3A+Use+Properties+instead+of+StreamsConfig+in+KafkaStreams+constructor >>>> >>>> >>>> to reflect the change proposed by Guozhang(adding a 4th constructor) >>>> >>>> >>>> Let me know your thoughts! >>>> >>>> >>>> Best, >>>> >>>> Boyang >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Boyang Chen <bche...@outlook.com> >>>> *Sent:* Saturday, January 13, 2018 9:37 AM >>>> *To:* Matthias J. Sax >>>> *Subject:* Re: Vote for KIP-245: Use Properties instead of StreamsConfig >>>> in KafkaStreams constructor >>>> >>>> >>>> Sounds good, will do. However I don't receive the +1 emails, interesting... >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Matthias J. Sax <matth...@confluent.io> >>>> *Sent:* Saturday, January 13, 2018 9:32 AM >>>> *To:* Boyang Chen >>>> *Subject:* Re: Vote for KIP-245: Use Properties instead of StreamsConfig >>>> in KafkaStreams constructor >>>> >>>> Guozhang left a comment about having a 4th overload. I agree that we >>>> should add this 4th overload. >>>> >>>> Please update the KIP accordingly and follow up on the mailing list >>>> thread. Than we can vote it through. >>>> >>>> Thx. >>>> >>>> -Matthias >>>> >>>> On 1/12/18 4:48 PM, Boyang Chen wrote: >>>>> Hey Matt, >>>>> >>>>> >>>>> I haven't received any approval/veto on this KIP. Everything is ready >>>>> but only needs one approval. Any step I should take? >>>>> >>>>> Thanks for the help! >>>>> >>>>> Boyang >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> *From:* Matthias J. Sax <matth...@confluent.io> >>>>> *Sent:* Saturday, January 13, 2018 3:47 AM >>>>> *To:* dev@kafka.apache.org >>>>> *Subject:* Re: Vote for KIP-245: Use Properties instead of StreamsConfig >>>>> in KafkaStreams constructor >>>>> >>>>> Boyang, >>>>> >>>>> what is the status of this KIP? The release plan for 1.1 was just >>>>> announced and we like to get this KIP into the release. >>>>> >>>>> Thx. >>>>> >>>>> >>>>> -Matthias >>>>> >>>>> On 1/2/18 11:18 AM, Guozhang Wang wrote: >>>>>> Boyang, >>>>>> >>>>>> Thanks for the proposed change, the wiki page lgtm. One minor comment >>>>>> otherwise I'm +1: >>>>>> >>>>>> For the new API, we now also have a constructor that accepts both a >>>>>> clientSupplier and a Time, so we should consider having four overloads in >>>>>> total: >>>>>> >>>>>> >>>>>> // New API (using Properties) >>>>>> public KafkaStreams(final Topology, final Properties props) >>>>>> public KafkaStreams(final Topology, final Properties props, final Time >>>>>> time) >>>>>> public KafkaStreams(final Topology, final Properties props, final >>>>>> KafkaClientSupplier >>>>>> clientSupplier) >>>>>> public KafkaStreams(final Topology, final Properties props, final >>>>>> KafkaClientSupplier >>>>>> clientSupplier, final Time time) >>>>>> >>>>>> Guozhang >>>>>> >>>>>> On Tue, Dec 26, 2017 at 7:26 PM, Satish Duggana >>>>>> <satish.dugg...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Thanks for the KIP, +1 from me. >>>>>>> >>>>>>> On Wed, Dec 27, 2017 at 7:42 AM, Bill Bejeck <bbej...@gmail.com> wrote: >>>>>>> >>>>>>>> Thanks for the KIP. +1 for me. >>>>>>>> >>>>>>>> On Tue, Dec 26, 2017 at 6:22 PM Ted Yu <yuzhih...@gmail.com> wrote: >>>>>>>> >>>>>>>>> +1 from me as well. >>>>>>>>> >>>>>>>>> On Tue, Dec 26, 2017 at 10:41 AM, Matthias J. Sax < >>>>>>> matth...@confluent.io >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Thanks for the KIP Boyang! >>>>>>>>>> >>>>>>>>>> I don't have any further comments. >>>>>>>>>> >>>>>>>>>> +1 from me. >>>>>>>>>> >>>>>>>>>> @Ted: This is a rather simple KIP, thus, skipping the DISCUSS thread >>>>>>>>>> seems ok to me. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Matthias >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> @Boyang: it's recommended to use this format for the subject >>>>>>>>>> >>>>>>>>>> "[VOTE] KIP-245: ..." >>>>>>>>>> >>>>>>>>>> Same for DISCUSS threads. People are used to those headlines and they >>>>>>>>>> pay more attention than. For this KIP, just leave it as it though. >>>>>>> For >>>>>>>>>> future reference only >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 12/26/17 4:55 AM, Ted Yu wrote: >>>>>>>>>>> Normally a DISCUSS thread precedes VOTE thread so that people have >>>>>>>>> ample >>>>>>>>>> time examining the proposal. >>>>>>>>>>> -------- Original message --------From: Boyang Chen < >>>>>>>>> bche...@outlook.com> >>>>>>>>>> Date: 12/26/17 1:22 AM (GMT-07:00) To: dev@kafka.apache.org >>>>>>> Subject: >>>>>>>>>> Vote for KIP-245: Use Properties instead of StreamsConfig in >>>>>>>> KafkaStreams >>>>>>>>>> constructor >>>>>>>>>>> Hi there, >>>>>>>>>>> >>>>>>>>>>> I'm Boyang who is a newbie contributor to Kafka. I would like to >>>>>>>> start >>>>>>>>> a >>>>>>>>>> vote for the KIP-245: >>>>>>>>>>> >>>>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP- >>>>>>>>>> >>>>>>>>> 245%3A+Use+Properties+instead+of+StreamsConfig+in+ >>>>>>>> KafkaStreams+constructor >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is linked with JIRA: https://issues.apache.org/ >>>>> issues.apache.org <https://issues.apache.org/> >>>> issues.apache.org <https://issues.apache.org/> >>>> issues.apache.org >>>> Apache currently hosts two different issue tracking systems, Bugzilla >>>> and Jira. To find out how to report an issue for a particular project, >>>> please visit the project ... >>>> >>>> >>>> >>>>> issues.apache.org >>>>> Apache currently hosts two different issue tracking systems, Bugzilla >>>>> and Jira. To find out how to report an issue for a particular project, >>>>> please visit the project ... >>>>> >>>>> >>>>> >>>>>>>>>> jira/browse/KAFKA-6386 >>>>>>>>>>> >>>>>>>>>>> [KAFKA-6386] Deprecate KafkaStreams constructor taking ...< >>>>>>>>>> https://issues.apache.org/jira/browse/KAFKA-6386> >>>> [KAFKA-6386] Deprecate KafkaStreams constructor taking ... >>>> <https://issues.apache.org/jira/browse/KAFKA-6386> >>>> issues.apache.org >>>> Currently, KafkaStreams constructor has overloads that take either >>>> Properties or StreamsConfig a parameters. Because StreamsConfig is >>>> immutable and is created from a ... >>>> >>>> >>>> >>>>> [KAFKA-6386] Deprecate KafkaStreams constructor taking ... >>>>> <https://issues.apache.org/jira/browse/KAFKA-6386> >>>> [KAFKA-6386] Deprecate KafkaStreams constructor taking ... >>>> <https://issues.apache.org/jira/browse/KAFKA-6386> >>>> issues.apache.org >>>> Currently, KafkaStreams constructor has overloads that take either >>>> Properties or StreamsConfig a parameters. Because StreamsConfig is >>>> immutable and is created from a ... >>>> >>>> >>>> >>>>> issues.apache.org >>>>> Currently, KafkaStreams constructor has overloads that take either >>>>> Properties or StreamsConfig a parameters. Because StreamsConfig is >>>>> immutable and is created from a ... >>>>> >>>>> >>>>> >>>>>>>>>>> issues.apache.org >>>>>>>>>>> Currently, KafkaStreams constructor has overloads that take either >>>>>>>>>> Properties or StreamsConfig a parameters. Because StreamsConfig is >>>>>>>>>> immutable and is created from a ... >>>>>>>>>>> >>>>>>>>>>> And my pull request is here: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://github.com/apache/kafka/pull/4354 >>>> <https://github.com/apache/kafka/pull/4354> >>>> >>>> KAFKA-6386:use Properties instead of StreamsConfig in KafkaStreams >>>> constructor by abbccdda · Pull Request #4354 · apache/kafka >>>> <https://github.com/apache/kafka/pull/4354> >>>> github.com >>>> This pull request targets >>>> https://issues.apache.org/jira/browse/KAFKA-6386 The minor fix to >>>> deprecate usage of StreamsConfig in favor of java.util.Properties. I >>>> created separate public constructors... >>>> >>>> >>>> >>>>> <https://github.com/apache/kafka/pull/4354> >>>> <https://github.com/apache/kafka/pull/4354> >>>> >>>> KAFKA-6386:use Properties instead of StreamsConfig in KafkaStreams >>>> constructor by abbccdda · Pull Request #4354 · apache/kafka >>>> <https://github.com/apache/kafka/pull/4354> >>>> github.com >>>> This pull request targets >>>> https://issues.apache.org/jira/browse/KAFKA-6386 The minor fix to >>>> deprecate usage of StreamsConfig in favor of java.util.Properties. I >>>> created separate public constructors... >>>> >>>> >>>> >>>>> >>>>> KAFKA-6386:use Properties instead of StreamsConfig in KafkaStreams >>>>> constructor by abbccdda · Pull Request #4354 · apache/kafka >>>>> <https://github.com/apache/kafka/pull/4354> >>>> <https://github.com/apache/kafka/pull/4354> >>>> >>>> KAFKA-6386:use Properties instead of StreamsConfig in KafkaStreams >>>> constructor by abbccdda · Pull Request #4354 · apache/kafka >>>> <https://github.com/apache/kafka/pull/4354> >>>> github.com >>>> This pull request targets >>>> https://issues.apache.org/jira/browse/KAFKA-6386 The minor fix to >>>> deprecate usage of StreamsConfig in favor of java.util.Properties. I >>>> created separate public constructors... >>>> >>>> >>>> >>>>> github.com >>>>> This pull request targets >>>>> https://issues.apache.org/jira/browse/KAFKA-6386 The minor fix to >>>> [KAFKA-6386] Deprecate KafkaStreams constructor taking ... >>>> <https://issues.apache.org/jira/browse/KAFKA-6386> >>>> issues.apache.org >>>> Currently, KafkaStreams constructor has overloads that take either >>>> Properties or StreamsConfig a parameters. Because StreamsConfig is >>>> immutable and is created from a ... >>>> >>>> >>>> >>>>> deprecate usage of StreamsConfig in favor of java.util.Properties. I >>>>> created separate public constructors... >>>>> >>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Since this is my first time doing this, feel free to let me know if >>>>>>>>> this >>>>>>>>>> is the correct format! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> >>>>>>>>>>> Boyang >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> Email had 1 attachment: >>> + signature.asc >>> 1k (application/pgp-signature) >
signature.asc
Description: OpenPGP digital signature
