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