flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Metzger <rmetz...@apache.org>
Subject Re: [PROPOSAL] Structure the Flink Open Source Development
Date Thu, 16 Jun 2016 17:02:52 GMT
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 <mxm@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 <rmetzger@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 <trohrmann@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 <sewen@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 <sewen@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.
> >> > > > > > > >>>>>>>>>
> >> > > > > > > >>>>>>
> >> > > > > > > >>>>>>
> >> > > > > > > >>>>
> >> > > > > > > >>>
> >> > > > > > > >>
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>

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