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