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