Thanks, everyone for voting and discussions. The KIP is passed with 3 binding 
votes from John, Matthias, and Guozhang and 1 non-binding vote from Bruno. 

    On Friday, 24 January, 2020, 08:50:21 am IST, Bruno Cadonna 
<br...@confluent.io> wrote:  
 
 Hi Navinder,

+1 (non-binding)

Best,
Bruno

On Thu, Jan 23, 2020 at 9:19 AM John Roesler <vvcep...@apache.org> wrote:
>
> Thanks, Navinder. It's just to give everyone a chance to object if they 
> wanted to.
> -John
>
> On Thu, Jan 23, 2020, at 00:44, Navinder Brar wrote:
> > Oh sorry, my bad. Will wait for another 12 hours.
> >
> >    On Thursday, 23 January, 2020, 12:09:57 pm IST, Matthias J. Sax
> > <matth...@confluent.io> wrote:
> >
> >  Navinder,
> >
> > a KIP vote must be open for 72h and cannot be closed earlier.
> >
> > -Matthias
> >
> > On 1/22/20 10:27 PM, Navinder Brar wrote:
> > > Thanks, everyone for voting. KIP-562 has been accepted with binding votes 
> > > from John, Matthias, and Guozhang.
> > >
> > >    On Thursday, 23 January, 2020, 09:40:07 am IST, Guozhang Wang 
> > ><wangg...@gmail.com> wrote:
> > >
> > >  +1 (binding) from me as well.
> > >
> > > On Wed, Jan 22, 2020 at 5:59 PM Matthias J. Sax <matth...@confluent.io>
> > > wrote:
> > >
> > >> I have a few minor comments (compare the DISCUSS thread), but overall
> > >> the KIP looks good.
> > >>
> > >> +1 (binding)
> > >>
> > >>
> > >> -Matthias
> > >>
> > >> On 1/22/20 10:09 AM, John Roesler wrote:
> > >>> Thanks for updating the KIP, Navinder.
> > >>>
> > >>> I'm +1 (binding) on the current proposal
> > >>>
> > >>> Thanks,
> > >>> -John
> > >>>
> > >>> On Tue, Jan 21, 2020, at 12:50, Navinder Brar wrote:
> > >>>> Thanks, Guozhang. I agree it makes total sense. I will make the
> > >>>> edits.~Navinder
> > >>>>
> > >>>>    On Tuesday, 21 January, 2020, 11:00:32 pm IST, Guozhang Wang
> > >>>> <wangg...@gmail.com> wrote:
> > >>>>
> > >>>>  Hello Navinder,
> > >>>>
> > >>>> Thanks for brining up this proposal. I made a quick pass on that and
> > >>>> overall I think I agree with your ideas. Just a few thoughts about the
> > >>>> public APIs:
> > >>>>
> > >>>> 1) As we are adding a new overload to `KafkaStreams#store`, could we
> > >> just
> > >>>> add the storeName and queryableStoreType as part of StoreQueryParam, 
> > >>>> and
> > >>>> leaving that the only parameter of the function?
> > >>>>
> > >>>> 2) along with 1), for the static constructors, instead of iterating 
> > >>>> over
> > >>>> all possible combos I'd suggest we make constructors with only, say,
> > >>>> storeName, and then adding `withXXX()` setters to set other fields.
> > >> This is
> > >>>> in case we want to add more param fields into the object, that we do 
> > >>>> not
> > >>>> need to exponentially adding and deprecating the static constructors.
> > >>>>
> > >>>>
> > >>>> Guozhang
> > >>>>
> > >>>>
> > >>>> On Mon, Jan 20, 2020 at 10:42 AM Navinder Brar
> > >>>> <navinder_b...@yahoo.com.invalid> wrote:
> > >>>>
> > >>>>> Hello all,
> > >>>>>
> > >>>>> I'd like to propose a vote to serve keys from a specific
> > >> partition-store
> > >>>>> instead of iterating over all the local stores of an instance to
> > >> locate the
> > >>>>> key, as which happens currently.
> > >>>>> The full KIP is provided here:
> > >>>>>
> > >>>>>
> > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-562%3A+Allow+fetching+a+key+from+a+single+partition+rather+than+iterating+over+all+the+stores+on+an+instance
> > >>>>>
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Navinder
> > >>>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> -- Guozhang
> > >>>>
> > >>
> > >>
> > >
> >
  

Reply via email to