flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Ewen <se...@apache.org>
Subject Re: [PROPOSAL] Structure the Flink Open Source Development
Date Wed, 08 Jun 2016 17:22:12 GMT
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.
> > >>>>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message