I added you to the DataStream API.
On Fri, Jun 17, 2016 at 5:36 PM, Kostas Kloudas wrote:
> Hello,
>
> You can also add me to the DataStream API.
>
> Kostas
>
> > On Jun 16, 2016, at 7:02 PM, Robert Metzger wrote:
> >
> > Cool, thank you.
> >
> > So now we have at least one shepherd for each co
Hello,
You can also add me to the DataStream API.
Kostas
> On Jun 16, 2016, at 7:02 PM, Robert Metzger 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.
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
@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 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:4
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 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, A
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
wrote:
> Should probably, yes.
>
> On Thu, 9 Jun 2016 at 10:53 Stephan Ewen wrote:
>
> > Should state bakends and checkpointing go together?
> >
> > The two of us could be
Should probably, yes.
On Thu, 9 Jun 2016 at 10:53 Stephan Ewen 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
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
wrote:
> I think it would make sense to also move "State Backends" out from
> "R
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 wrote:
> I am add
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 Tu
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 wrote:
> Hi all,
>
> +1 for shepherd
> I would like to
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 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 devel
+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
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 wrote:
> I think calling the rol
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 wrote:
> sounds like "Observer" would fit.
>
>
> On 01.06.2016 19:11, Fabian Hueske 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 a
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 m
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 wrote:
> Btw, i
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 wrote:
> I'd also go with maintainer.
>
> On 01.06.2016 10:32, Aljoscha Krettek wrote:
> > Hi,
> > I think maintainer is
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
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
wrote:
> Hi,
>
> we could go for something like "sponsor" or "champion" :)
> I'm f
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 wrote:
> I'd like to be added to the Streaming Connectors component (already edited
>
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, es
Overseer? Supervisor? Warden?
2016-05-31 21:23 GMT+02:00 Robert Metzger :
> Good point. I haven't thought about this name clash.
> However, I wonder whether it is clear from the context whether we are
> talking about pull request and component shepherding.
>
> Are there any other ideas for the
Good point. I haven't thought about this name clash.
However, I wonder whether it is clear from the context whether we are
talking about pull request and component shepherding.
Are there any other ideas for the name? If nobody else has concerns
regarding the "maintainer" name, we can of course kee
so are we discarding the other "shepherd" role then?
On 31.05.2016 19:47, Robert Metzger wrote:
Hi,
to keep this discussion going, I pasted Stephan's Component proposal into
the Wiki:
https://cwiki.apache.org/confluence/display/FLINK/Components+and+Shepherds
Also, I suggest to rename the "main
Hi,
to keep this discussion going, I pasted Stephan's Component proposal into
the Wiki:
https://cwiki.apache.org/confluence/display/FLINK/Components+and+Shepherds
Also, I suggest to rename the "maintainer" to "shepherd" to reflect that
still the committers and the PMC is in charge and the shepher
Hi!
Thanks for all the comments, and the positive resonance! Looks like so far
all are in favor.
I would next add a section to the Wiki and the "How to Contribute" Guide on
this structure, incorporating the component split of Optimizer and Client.
After that, let's get started with gathering can
+1 to Henry's comment, once this makes it to the wiki/website the wording
needs to make it clear that the governance model is unchanged
On Mon, May 16, 2016 at 10:02 AM, Theodore Vasiloudis <
theodoros.vasilou...@gmail.com> wrote:
> I like the idea of having maintainers as well, hopefully we can
I like the idea of having maintainers as well, hopefully we can streamline
the reviewing process.
I of course can volunteer for the FlinkML component.
As I've mentioned before I'd love to get one more committer willing to
review PRs in FlinkML; by my last count we were up to ~20 open ML-related
PR
The maintainers concept is good idea to make sure PRs are moved smoothly.
But, we need to make sure that this is not additional hierarchy on top of
Flink PMCs.
This will keep us in spirit of ASF community over code.
Please do add me as cluster management maintainer member.
- Henry
On Tuesday, M
I like the proposal and especially the goal to improve the metadata and
descriptions of JIRA issues.
However, I would like to split Client and Optimizer into separate
components.
I can be a maintainer of the optimizer component (DataSet + SQL are fine as
well).
Cheers, Fabian
2016-05-13 17:03
+1 to better scaling :)
Many Jira tickets are good ideas with no current traction. Some have a pull
request (usually closed), many have comments or discussion. It seems these
old tickets tend to hang around because closing the ticket feels like
rejecting the idea. How do we track requested feature
Sounds like a good idea to me. We could include Wikipedia article as well.
As was thinking about extending the article anyway (no time so far...),
as of Flink 1.x the system is stable in large parts and it might be nice
to have a high level system description on Wikipedia, too.
-Matthias
On 05/
Should we also add a component "Flink website and wiki" (minus the
documentation) with an associated maintainer?
On Fri, May 13, 2016 at 12:17 PM, Timo Walther wrote:
> +1 for from my side too
>
>
>
> On 13.05.2016 06:13, Chiwan Park wrote:
>
>> +1 for this proposal
>>
>
>
>
+1 for from my side too
On 13.05.2016 06:13, Chiwan Park wrote:
+1 for this proposal
Thanks for great suggestion.
+1 for this proposal.
Regards,
Chiwan Park
> On May 13, 2016, at 1:44 AM, Nick Dimiduk wrote:
>
> For what it's worth, this is very close to how HBase attempts to manage the
> community load. We break out components (in Jira), with a list of named
> component maint
For what it's worth, this is very close to how HBase attempts to manage the
community load. We break out components (in Jira), with a list of named
component maintainers. Actually, having components alone has given a Big
Bang for the buck because when properly labeled, it makes it really easy
for p
+1
The ideas seem good and the proposed number of components seems reasonable.
With this, we should also then cleanup the JIRA to make it actually usable.
On Thu, 12 May 2016 at 18:09 Stephan Ewen wrote:
> All maintainer candidates are only proposals so far. No indication of lead
> or anything
All maintainer candidates are only proposals so far. No indication of lead
or anything so far.
Let's first see if we agree on the structure proposed here, and if we take
the components as suggested here or if we refine the list.
Am 12.05.2016 17:45 schrieb "Robert Metzger" :
> tl;dr: +1
>
> I als
tl;dr: +1
I also like the proposal a lot. Our community is growing at a quite fast
pace and we need to have some structure in place to still keep track of
everything going on.
I'm happy to see that the proposal mentions cleaning up our JIRA. This is
something that has been annoying me for quite a
+1 for the initiative. With a better process we will improve the
quality of the Flink development and give us more time to focus.
Could we have another category "Infrastructure"? This would concern
things like CI, nightly deployment of snapshots/documentation, ASF
Infra communication. Robert and m
Hey Stephan!
Thanks to you and the others who started this. I really like the
proposal and I'm happy to see my name on some components.
So, +1.
I'd say let's wait until the end of the week/beginning of next week to
see if there is any disagreement with the propsal in the community
(doesn't look
Yes, Matthias, that was supposed to be you.
Sorry from another guy who frequently has his name misspelled ;-)
On Thu, May 12, 2016 at 1:27 PM, Matthias J. Sax wrote:
> +1 from my side.
>
> Happy to be the maintainer for Storm-Compatibiltiy (at least I guess
> it's me, even the correct spelling w
Big +1 from my side, I think this will help the community grow and prosper
big time!
On Thu, May 12, 2016 at 1:27 PM, Matthias J. Sax wrote:
> +1 from my side.
>
> Happy to be the maintainer for Storm-Compatibiltiy (at least I guess
> it's me, even the correct spelling would be with two 't' :P)
+1 from my side.
Happy to be the maintainer for Storm-Compatibiltiy (at least I guess
it's me, even the correct spelling would be with two 't' :P)
-Matthias
On 05/12/2016 12:56 PM, Till Rohrmann wrote:
> +1 for the proposal
> On May 12, 2016 12:13 PM, "Stephan Ewen" wrote:
>
>> Yes, Gabor Geva
+1 for the proposal
On May 12, 2016 12:13 PM, "Stephan Ewen" wrote:
> Yes, Gabor Gevay, that did refer to you!
>
> Sorry for the ambiguity...
>
> On Thu, May 12, 2016 at 10:46 AM, Márton Balassi >
> wrote:
>
> > +1 for the proposal
> > @ggevay: I do think that it refers to you. :)
> >
> > On Thu
Yes, Gabor Gevay, that did refer to you!
Sorry for the ambiguity...
On Thu, May 12, 2016 at 10:46 AM, Márton Balassi
wrote:
> +1 for the proposal
> @ggevay: I do think that it refers to you. :)
>
> On Thu, May 12, 2016 at 10:40 AM, Gábor Gévay wrote:
>
> > Hello,
> >
> > There are at least thr
+1 for the proposal
@ggevay: I do think that it refers to you. :)
On Thu, May 12, 2016 at 10:40 AM, Gábor Gévay wrote:
> Hello,
>
> There are at least three Gábors in the Flink community, :) so
> assuming that the Gábor in the list of maintainers of the DataSet API
> is referring to me, I'll be
Hello,
There are at least three Gábors in the Flink community, :) so
assuming that the Gábor in the list of maintainers of the DataSet API
is referring to me, I'll be happy to do it. :)
Best,
Gábor G.
2016-05-10 11:24 GMT+02:00 Stephan Ewen :
> Hi everyone!
>
> We propose to establish some li
50 matches
Mail list logo
