[PROPOSAL] Structure the Flink Open Source Development

[Robert Metzger]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>:
> >>>
> >>>> 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 <
> [hidden email]
> >>>
> >>>> 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 <[hidden email]>
> >>> 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 <
> >>>> [hidden email]>
> >>>>>>> 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 <[hidden email]
> >>>
> >>>>>> 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.
> >>>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >>
>
>

[Stephan Ewen]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> > 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 <[hidden email]>
> 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 <[hidden email]>
> > 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 <[hidden email]>:
> > >>>
> > >>>> 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 <
> > [hidden email]
> > >>>
> > >>>> 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 <[hidden email]>
> > >>> 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 <
> > >>>> [hidden email]>
> > >>>>>>> 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 <
> [hidden email]
> > >>>
> > >>>>>> 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.
> > >>>>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>

[Aljoscha Krettek-2]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> > 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 <[hidden email]>
> > > 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 <[hidden email]>
> > 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 <[hidden email]>
> > > 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 <[hidden email]>:
> > > >>>
> > > >>>> 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 <
> > > [hidden email]
> > > >>>
> > > >>>> 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 <[hidden email]
> >
> > > >>> 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 <
> > > >>>> [hidden email]>
> > > >>>>>>> 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 <
> > [hidden email]
> > > >>>
> > > >>>>>> 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.
> > > >>>>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>

[Stephan Ewen]

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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> > > 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 <[hidden email]
> >
> > > > 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 <[hidden email]>
> > > 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 <[hidden email]>
> > > > 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 <[hidden email]>:
> > > > >>>
> > > > >>>> 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 <
> > > > [hidden email]
> > > > >>>
> > > > >>>> 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 <
> [hidden email]
> > >
> > > > >>> 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 <
> > > > >>>> [hidden email]>
> > > > >>>>>>> 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 <
> > > [hidden email]
> > > > >>>
> > > > >>>>>> 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.
> > > > >>>>>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>

[Aljoscha Krettek-2]

Should probably, yes.

On Thu, 9 Jun 2016 at 10:53 Stephan Ewen <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> > > 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 <[hidden email]>
> > > > 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 <
> [hidden email]
> > >
> > > > > 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 <[hidden email]>
> > > > 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 <
> [hidden email]>
> > > > > 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 <[hidden email]>:
> > > > > >>>
> > > > > >>>> 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 <
> > > > > [hidden email]
> > > > > >>>
> > > > > >>>> 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 <
> > [hidden email]
> > > >
> > > > > >>> 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 <
> > > > > >>>> [hidden email]>
> > > > > >>>>>>> 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 <
> > > > [hidden email]
> > > > > >>>
> > > > > >>>>>> 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.
> > > > > >>>>>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

[Till Rohrmann]

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 <[hidden email]>
wrote:

> Should probably, yes.
>
> On Thu, 9 Jun 2016 at 10:53 Stephan Ewen <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]> 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 <[hidden email]>
> > > > 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 <
> [hidden email]>
> > > > > 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 <
> > [hidden email]
> > > >
> > > > > > 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 <
> [hidden email]>
> > > > > 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 <
> > [hidden email]>
> > > > > > 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 <[hidden email]>:
> > > > > > >>>
> > > > > > >>>> 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 <
> > > > > > [hidden email]
> > > > > > >>>
> > > > > > >>>> 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 <
> > > [hidden email]
> > > > >
> > > > > > >>> 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 <
> > > > > > >>>> [hidden email]>
> > > > > > >>>>>>> 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 <
> > > > > [hidden email]
> > > > > > >>>
> > > > > > >>>>>> 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.
> > > > > > >>>>>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Robert Metzger]

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 <[hidden email]> 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 <[hidden email]>
> wrote:
>
> > Should probably, yes.
> >
> > On Thu, 9 Jun 2016 at 10:53 Stephan Ewen <[hidden email]> 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 <[hidden email]>
> > > 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 <[hidden email]> 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 <
> [hidden email]>
> > > > > 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 <
> > [hidden email]>
> > > > > > 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 <
> > > [hidden email]
> > > > >
> > > > > > > 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 <
> > [hidden email]>
> > > > > > 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 <
> > > [hidden email]>
> > > > > > > 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 <[hidden email]>:
> > > > > > > >>>
> > > > > > > >>>> 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 <
> > > > > > > [hidden email]
> > > > > > > >>>
> > > > > > > >>>> 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 <
> > > > [hidden email]
> > > > > >
> > > > > > > >>> 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 <
> > > > > > > >>>> [hidden email]>
> > > > > > > >>>>>>> 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 <
> > > > > > [hidden email]
> > > > > > > >>>
> > > > > > > >>>>>> 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.
> > > > > > > >>>>>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>
> > > > > > > >>>
> > > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[mxm]

@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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> wrote:
>>
>> > Should probably, yes.
>> >
>> > On Thu, 9 Jun 2016 at 10:53 Stephan Ewen <[hidden email]> 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 <[hidden email]>
>> > > 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 <[hidden email]> 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 <
>> [hidden email]>
>> > > > > 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 <
>> > [hidden email]>
>> > > > > > 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 <
>> > > [hidden email]
>> > > > >
>> > > > > > > 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 <
>> > [hidden email]>
>> > > > > > 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 <
>> > > [hidden email]>
>> > > > > > > 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 <[hidden email]>:
>> > > > > > > >>>
>> > > > > > > >>>> 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 <
>> > > > > > > [hidden email]
>> > > > > > > >>>
>> > > > > > > >>>> 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 <
>> > > > [hidden email]
>> > > > > >
>> > > > > > > >>> 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 <
>> > > > > > > >>>> [hidden email]>
>> > > > > > > >>>>>>> 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 <
>> > > > > > [hidden email]
>> > > > > > > >>>
>> > > > > > > >>>>>> 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.
>> > > > > > > >>>>>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>
>> > > > > > > >>>
>> > > > > > > >>
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>

[Robert Metzger]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>
> >> wrote:
> >>
> >> > Should probably, yes.
> >> >
> >> > On Thu, 9 Jun 2016 at 10:53 Stephan Ewen <[hidden email]> 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 <
> [hidden email]>
> >> > > 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 <[hidden email]>
> 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 <
> >> [hidden email]>
> >> > > > > 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 <
> >> > [hidden email]>
> >> > > > > > 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 <
> >> > > [hidden email]
> >> > > > >
> >> > > > > > > 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 <
> >> > [hidden email]>
> >> > > > > > 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 <
> >> > > [hidden email]>
> >> > > > > > > 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 <[hidden email]
> >:
> >> > > > > > > >>>
> >> > > > > > > >>>> 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 <
> >> > > > > > > [hidden email]
> >> > > > > > > >>>
> >> > > > > > > >>>> 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 <
> >> > > > [hidden email]
> >> > > > > >
> >> > > > > > > >>> 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 <
> >> > > > > > > >>>> [hidden email]>
> >> > > > > > > >>>>>>> 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 <
> >> > > > > > [hidden email]
> >> > > > > > > >>>
> >> > > > > > > >>>>>> 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.
> >> > > > > > > >>>>>>>>>
> >> > > > > > > >>>>>>
> >> > > > > > > >>>>>>
> >> > > > > > > >>>>
> >> > > > > > > >>>
> >> > > > > > > >>
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>

[Kostas Kloudas]

Hello,

You can also add me to the DataStream API.

Kostas

> On Jun 16, 2016, at 7:02 PM, Robert Metzger <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]>
>> 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 <[hidden email]>
>>>> wrote:
>>>>
>>>>> Should probably, yes.
>>>>>
>>>>> On Thu, 9 Jun 2016 at 10:53 Stephan Ewen <[hidden email]> 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 <
>> [hidden email]>
>>>>>> 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 <[hidden email]>
>> 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 <
>>>> [hidden email]>
>>>>>>>> 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 <
>>>>> [hidden email]>
>>>>>>>>> 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 <
>>>>>> [hidden email]
>>>>>>>>
>>>>>>>>>> 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 <
>>>>> [hidden email]>
>>>>>>>>> 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 <
>>>>>> [hidden email]>
>>>>>>>>>> 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 <[hidden email]
>>> :
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 <
>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 <
>>>>>>> [hidden email]
>>>>>>>>>
>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>> [hidden email]
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>

[Robert Metzger]

I added you to the DataStream API.

On Fri, Jun 17, 2016 at 5:36 PM, Kostas Kloudas <[hidden email]
> wrote:

> Hello,
>
> You can also add me to the DataStream API.
>
> Kostas
>
> > On Jun 16, 2016, at 7:02 PM, Robert Metzger <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> >> 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 <[hidden email]>
> >> 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 <
> [hidden email]>
> >>>> wrote:
> >>>>
> >>>>> Should probably, yes.
> >>>>>
> >>>>> On Thu, 9 Jun 2016 at 10:53 Stephan Ewen <[hidden email]> 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 <
> >> [hidden email]>
> >>>>>> 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 <[hidden email]>
> >> 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 <
> >>>> [hidden email]>
> >>>>>>>> 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 <
> >>>>> [hidden email]>
> >>>>>>>>> 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 <
> >>>>>> [hidden email]
> >>>>>>>>
> >>>>>>>>>> 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 <
> >>>>> [hidden email]>
> >>>>>>>>> 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 <
> >>>>>> [hidden email]>
> >>>>>>>>>> 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 <[hidden email]
> >>> :
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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 <
> >>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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 <
> >>>>>>> [hidden email]
> >>>>>>>>>
> >>>>>>>>>>>>> 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 <
> >>>>>>>>>>>>>> [hidden email]>
> >>>>>>>>>>>>>>>>> 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 <
> >>>>>>>>> [hidden email]
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
>
>