I added you to the DataStream API. On Fri, Jun 17, 2016 at 5:36 PM, Kostas Kloudas <k.klou...@data-artisans.com > wrote:
> Hello, > > You can also add me to the DataStream API. > > Kostas > > > On Jun 16, 2016, at 7:02 PM, Robert Metzger <rmetz...@apache.org> wrote: > > > > Cool, thank you. > > > > So now we have at least one shepherd for each component. > > Since there were no other comments / complaints about this proposal, I > > assume its "active" now. > > > > It would be nice if the component shepherds could clean up the JIRA a > bit. > > I will try to consolidate the existing components in our JIRA to the > > proposed table. > > > > > > On Thu, Jun 16, 2016 at 5:53 PM, Maximilian Michels <m...@apache.org> > wrote: > > > >> @Robert You can put me as the shepherd for the "Client" component for > now. > >> > >> On Wed, Jun 15, 2016 at 10:02 PM, Robert Metzger <rmetz...@apache.org> > >> wrote: > >>> I moved the State Backend to the Checkpointing and added the three of > you > >>> as shepherds. > >>> > >>> We still need somebody for the client. > >>> > >>> On Thu, Jun 9, 2016 at 11:41 AM, Till Rohrmann <trohrm...@apache.org> > >> wrote: > >>> > >>>> I agree. I could be the third backup if you need help with the > >> component. > >>>> > >>>> On Thu, Jun 9, 2016 at 11:33 AM, Aljoscha Krettek < > aljos...@apache.org> > >>>> wrote: > >>>> > >>>>> Should probably, yes. > >>>>> > >>>>> On Thu, 9 Jun 2016 at 10:53 Stephan Ewen <se...@apache.org> wrote: > >>>>> > >>>>>> Should state bakends and checkpointing go together? > >>>>>> > >>>>>> The two of us could be shepherds for that. Till would be another > >> person > >>>>>> (but he has a lot of components already). > >>>>>> > >>>>>> On Wed, Jun 8, 2016 at 9:22 PM, Aljoscha Krettek < > >> aljos...@apache.org> > >>>>>> wrote: > >>>>>> > >>>>>>> I think it would make sense to also move "State Backends" out from > >>>>>>> "Runtime". This is also quite complex on it's own. I would of > >> course > >>>>>>> volunteer for this and I think Stephan, who is the current > >> proposal > >>>> for > >>>>>>> "Runtime" would also be good. > >>>>>>> > >>>>>>> On Wed, 8 Jun 2016 at 19:22 Stephan Ewen <se...@apache.org> > >> wrote: > >>>>>>> > >>>>>>>> I am adding a dedicated component for "Checkpointing". It would > >>>>> include > >>>>>>> the > >>>>>>>> checkpoint coordinator, barriers, threads, state handles and > >>>>> recovery. > >>>>>>>> > >>>>>>>> I think that part is big and complex enough to warrant its own > >>>>>> shepherd. > >>>>>>> I > >>>>>>>> would volunteer for that and be happy to also have a second > >>>> shepherd. > >>>>>>>> > >>>>>>>> On Tue, Jun 7, 2016 at 7:51 PM, Robert Metzger < > >>>> rmetz...@apache.org> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Okay, it seems that we agree on the Shepherd name. > >>>>>>>>> > >>>>>>>>> Also, it seems that everyone agrees to the proposed shepherds > >> so > >>>>> far. > >>>>>>>>> > >>>>>>>>> The "Client" component still needs a shepherd. Are there any > >>>>>>> volunteers? > >>>>>>>>> > >>>>>>>>> On Fri, Jun 3, 2016 at 12:07 PM, Chiwan Park < > >>>>> chiwanp...@apache.org> > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> Hi all, > >>>>>>>>>> > >>>>>>>>>> +1 for shepherd > >>>>>>>>>> I would like to add me to shepherd for FlinkML. > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> Chiwan Park > >>>>>>>>>> > >>>>>>>>>>> On Jun 3, 2016, at 3:29 AM, Henry Saputra < > >>>>>> henry.sapu...@gmail.com > >>>>>>>> > >>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> +1 for shepherd > >>>>>>>>>>> > >>>>>>>>>>> I would prefer using that term rather than maintainer. It > >> is > >>>>>> being > >>>>>>>> used > >>>>>>>>>> in > >>>>>>>>>>> Incubator PMC to help them keeping healthy development in > >>>>>> podlings. > >>>>>>>>>>> > >>>>>>>>>>> The term "maintainer" kind of being scrutinized in ASF > >>>>>> communities, > >>>>>>>> in > >>>>>>>>>>> recent episodes happening in Spark community. > >>>>>>>>>>> > >>>>>>>>>>> - Henry > >>>>>>>>>>> > >>>>>>>>>>> On Wed, Jun 1, 2016 at 12:00 PM, Stephan Ewen < > >>>>> se...@apache.org> > >>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> I like the name "shepherd". It implies a non-authorative > >>>> role, > >>>>>> and > >>>>>>>>>> implies > >>>>>>>>>>>> guidance, which is very fitting. > >>>>>>>>>>>> > >>>>>>>>>>>> I also thing there is no problem with having a "component > >>>>>>> shepherd" > >>>>>>>>> and > >>>>>>>>>> a > >>>>>>>>>>>> "pull request shepherd". > >>>>>>>>>>>> > >>>>>>>>>>>> Stephan > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Wed, Jun 1, 2016 at 7:11 PM, Fabian Hueske < > >>>>>> fhue...@gmail.com> > >>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> I think calling the role maintainer is not a good idea. > >>>>>>>>>>>>> The Spark community had a maintainer process which they > >>>> just > >>>>>>> voted > >>>>>>>> to > >>>>>>>>>>>>> remove. From my understanding, a maintainer in Spark > >> had a > >>>>> more > >>>>>>>>> active > >>>>>>>>>>>> role > >>>>>>>>>>>>> than the role we are currently discussing. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I would prefer to not call the role "maintainer" to make > >>>>> clear > >>>>>>> that > >>>>>>>>> the > >>>>>>>>>>>>> responsibilities are different (less active) and mainly > >>>>>>> observing. > >>>>>>>>>>>>> > >>>>>>>>>>>>> 2016-06-01 13:14 GMT+02:00 Ufuk Celebi <u...@apache.org > >>> : > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks! I like the idea of renaming it. I'm fine with > >>>>>> shepherd > >>>>>>>> and > >>>>>>>>> I > >>>>>>>>>>>>>> also like Vasia's suggestion "champion". > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I would like to add "Distributed checkpoints" as a > >>>> separate > >>>>>>>>> component > >>>>>>>>>>>>>> to track development for check- and savepoints. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Wed, Jun 1, 2016 at 10:59 AM, Aljoscha Krettek < > >>>>>>>>>> aljos...@apache.org > >>>>>>>>>>>>> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> Btw, in Jira, if we clean up our components we can > >> also > >>>>> set a > >>>>>>>>>>>> component > >>>>>>>>>>>>>>> Lead that would get notified of issues for that > >>>> component. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Wed, 1 Jun 2016 at 10:43 Chesnay Schepler < > >>>>>>> ches...@apache.org > >>>>>>>>> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I'd also go with maintainer. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On 01.06.2016 10:32, Aljoscha Krettek wrote: > >>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>> I think maintainer is also fine if we clearly > >> specify > >>>>> that > >>>>>>> they > >>>>>>>>>>>> are > >>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>> meant as dictators or gatekeepers of the component > >> that > >>>>>> they > >>>>>>>> are > >>>>>>>>>>>>>>>>> responsible for. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> -Aljoscha > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Wed, 1 Jun 2016 at 09:48 Vasiliki Kalavri < > >>>>>>>>>>>>>> vasilikikala...@gmail.com> > >>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> we could go for something like "sponsor" or > >> "champion" > >>>>> :) > >>>>>>>>>>>>>>>>>> I'm fine with the proposal. Good to see more than 1 > >>>>> person > >>>>>>> for > >>>>>>>>>>>> both > >>>>>>>>>>>>>>>> Gelly > >>>>>>>>>>>>>>>>>> and Table API. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> cheers, > >>>>>>>>>>>>>>>>>> -V. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On 1 June 2016 at 05:46, Tzu-Li (Gordon) Tai < > >>>>>>>>> tzuli...@gmail.com > >>>>>>>>>>>>> > >>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> I'd like to be added to the Streaming Connectors > >>>>>> component > >>>>>>>>>>>>> (already > >>>>>>>>>>>>>>>>>> edited > >>>>>>>>>>>>>>>>>>> Wiki) :) > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Ah, naming, one of the hardest problems in > >>>> programming > >>>>> :P > >>>>>>>> Some > >>>>>>>>>>>>>>>> comments: > >>>>>>>>>>>>>>>>>>> I agree with Robert that the name "maintainers" > >> will > >>>> be > >>>>>>>>> somewhat > >>>>>>>>>>>>>>>>>> misleading > >>>>>>>>>>>>>>>>>>> regarding the authoritative difference with > >>>> committers > >>>>> / > >>>>>>>> PMCs, > >>>>>>>>>>>>>>>> especially > >>>>>>>>>>>>>>>>>>> for future newcomers to the community who don't > >> come > >>>>>> across > >>>>>>>> the > >>>>>>>>>>>>>>>> original > >>>>>>>>>>>>>>>>>>> discussion on this thread. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Simone's suggestion of Overseer seems good. The > >> name > >>>>>>>> naturally > >>>>>>>>>>>>>> matches > >>>>>>>>>>>>>>>>>> its > >>>>>>>>>>>>>>>>>>> role - > >>>>>>>>>>>>>>>>>>> - A group of "Overseers" for components, who > >> keeps an > >>>>> eye > >>>>>>> on > >>>>>>>>>>>>> related > >>>>>>>>>>>>>>>> mail > >>>>>>>>>>>>>>>>>>> threads, known limitations and issues, JIRAs, open > >>>> PRs, > >>>>>>>>>>>> requested > >>>>>>>>>>>>>>>>>> features, > >>>>>>>>>>>>>>>>>>> and potential new overseers and committers, etc, > >> for > >>>>> the > >>>>>>>>>>>> component > >>>>>>>>>>>>>>>>>>> (original > >>>>>>>>>>>>>>>>>>> maintainer role). > >>>>>>>>>>>>>>>>>>> - A "Shepherd" for individual PRs, assigned from > >> the > >>>>>>>> overseers > >>>>>>>>>>>> of > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>> component with the aim to guide the submitting > >>>>>> contributor. > >>>>>>>>>>>>>> Overseers > >>>>>>>>>>>>>>>>>>> typically pick up new PRs to shepherd themselves, > >> or > >>>>> the > >>>>>>>>> leading > >>>>>>>>>>>>>>>> overseer > >>>>>>>>>>>>>>>>>>> allocates an overseer to shepherd a PR which > >> hasn't > >>>>> been > >>>>>>>> picked > >>>>>>>>>>>> up > >>>>>>>>>>>>>> yet > >>>>>>>>>>>>>>>>>>> after > >>>>>>>>>>>>>>>>>>> a certain period of time. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Or perhaps we can also simply go for "Shepherds" > >> for > >>>>>>>> components > >>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>> "Assigned Shepherd" for individual PRs? > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>> View this message in context: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >> > http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/PROPOSAL-Structure-the-Flink-Open-Source-Development-tp11598p11932.html > >>>>>>>>>>>>>>>>>>> Sent from the Apache Flink Mailing List archive. > >>>>> mailing > >>>>>>> list > >>>>>>>>>>>>>> archive > >>>>>>>>>>>>>>>> at > >>>>>>>>>>>>>>>>>>> Nabble.com. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >> > >
