Hi Becket, Big +1 on this.
> Regarding the vote of FLIP, preferably at least includes a PMC vote. Perhaps what Jincheng means is to hold at least one PMC in the 3 binding votes? i.e, the vote could have 2 binding committers and 1 PMC. I think this makes sense considering a FLIP could somehow be a big feature which may impacts Flink a lot. Meanwhile, there is no loss of flexibility as committers also have a chance to vote and participate in it. ========Seperator======== For the nice bylaws, I agree with the general idea and most of the content. Only share some thoughts about the "2/3 Majority". The main concern is I am not sure if it is doable in practice. The reasons are: 1. If we follow the bylaws strictly, it means a committer or a PMC member is active if he or she sends one email to the mailing list every 6 months. While the minimum length of the vote is only 6 days. There are chances that during the vote, some of the active members are still offline of the community. 2. The code of Flink is changing fast and not everyone fully understands every part. We don't need to force people to vote if they are not sure about it. It may also make the final result less credible. Given the above reasons, perhaps we can change the 2/3 Majority to lazy 2/3 Majority, just as the Hadoop bylaws[1]. It makes a higher threshold, however, more practical. What do you think? [1] https://hadoop.apache.org/bylaws.html On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <becket....@gmail.com> wrote: > Hi Jincheng, > > Thanks for the comments. I replied on the wiki page. Just a brief summary, > the current bylaws do require some of the FLIPs to get PMC approval if > their impact is big enough. But it leaves majority of the technical > decisions to the committers who are supposed to be responsible for making > such decisions. > > Re: Robert, > > I agree we can simply remove the requirement of +1 from a non-author > committer and revisit it in a bit. After all, it does not make sense to > have a bylaw that we cannot afford. I have just updated the bylaws wiki. > > Thanks, > > Jiangjie (Becket) Qin > > On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <rmetz...@apache.org> > wrote: > > > Hi all, > > I agree with Aljoscha that trying to reflect the current status in the > > bylaws, and then implementing changes one by one is a very involved task. > > Unless there's somebody who's really eager to drive this, I would stick > to > > Becket's initiative to come up with Bylaws for Flink, even if this means > > some changes. > > > > The cross-review requirement is the last big open point in this > discussion. > > It seems that a there is a slight tendency in the discussion that this is > > not feasible given the current pull request review situation. > > For the sake of bringing this discussion to a conclusion, I'm fine with > > leaving this requirement out. As we are currently adding more committers > to > > the project, we might be able to revisit this discussion in 3 - 6 months. > > > > > > On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <sunjincheng...@gmail.com> > > wrote: > > > > > Hi Becket, > > > > > > Thanks for the proposal. > > > > > > Regarding the vote of FLIP, preferably at least includes a PMC vote. > > > Because FLIP is usually a big change or affects the user's interface > > > changes. What do you think? (I leave the comment in the wiki.) > > > > > > Best, > > > Jincheng > > > > > > Dawid Wysakowicz <dwysakow...@apache.org> 于2019年7月17日周三 下午9:12写道： > > > > > > > Hi all, > > > > > > > > Sorry for joining late. I just wanted to say that I really like the > > > > proposed bylaws! > > > > > > > > One comment, I also have the same concerns as expressed by few people > > > > before that the "committer +1" on code change might be hard to > achieve > > > > currently. On the other hand I would say this would be beneficial for > > > > the quality/uniformity of our codebase and knowledge sharing. > > > > > > > > I was just wondering what should be the next step for this? I think > it > > > > would make sense to already use those bylaws and put them to PMC > vote. > > > > > > > > Best, > > > > > > > > Dawid > > > > > > > > On 12/07/2019 13:35, Piotr Nowojski wrote: > > > > > Hi Aljoscha and Becket > > > > > > > > > > Right, 3 days for FLIP voting is fine I think. > > > > > > > > > >>> I’m missing this stated somewhere clearly. If we are stating > that a > > > > single > > > > >>> committers +1 is good enough for code review, with 0 hours delay > > (de > > > > facto > > > > >>> the current state), we should also write down that this is > subject > > to > > > > the > > > > >>> best judgement of the committer to respect the components > expertise > > > and > > > > >>> ongoing development plans (also the de facto current state). > > > > >> Adding the statement would help clarify the intention, but it may > > be a > > > > >> little difficult to enforce and follow.. > > > > > I would be fine with that, it’s a soft/vague rule anyway, intended > to > > > be > > > > used with your “best judgemenet". I would like to just avoid a > > situation > > > > when someone violates current uncodified state and refers to the > bylaws > > > > which are saying merging with any committer +1 is always fine (like > > mine > > > +1 > > > > for flink-python or flink-ml). > > > > > > > > > > Piotrek > > > > > > > > > >> On 12 Jul 2019, at 11:29, Aljoscha Krettek <aljos...@apache.org> > > > wrote: > > > > >> > > > > >> @Piotr regarding the 3 days voting on the FLIP. This is just about > > the > > > > voting, before that there needs to be the discussion thread. If three > > > days > > > > have passed on a vote and there is consensus (i.e. 3 committers/PMCs > > have > > > > voted +1) that seems a high enough bar for me. So far, we have rarely > > see > > > > any FLIPs pass that formal bar. > > > > >> > > > > >> According to the recent META-FLIP thread, we want to use "lazy > > > > majority" for the FLIP voting process. I think that should be changed > > > from > > > > “consensus” in the proposed bylaws. > > > > >> > > > > >> Regarding the current state: do we have a current state that we > all > > > > agree on? I have the feeling that if we try to come up with something > > > that > > > > reflects the common state, according to PMCs/commiters, that might > > take a > > > > very long time. In that case I think it’s better to adopt something > > that > > > we > > > > all like, rather than trying to capture how we do it now. > > > > >> > > > > >> Aljoscha > > > > >> > > > > >>> On 12. Jul 2019, at 11:07, Piotr Nowojski <pi...@ververica.com> > > > wrote: > > > > >>> > > > > >>> Hi, > > > > >>> > > > > >>> Thanks for the proposal. Generally speaking +1 from my side to > the > > > > general idea and most of the content. I also see merit to the > Chesney's > > > > proposal to start from the current state. I think either would be > fine > > > for > > > > me. > > > > >>> > > > > >>> Couple of comments: > > > > >>> > > > > >>> 1. > > > > >>> > > > > >>> I also think that requiring +1 from another committer would slow > > down > > > > and put even more strain on the current reviewing bottleneck that we > > are > > > > having. Even if the change clear and simple, context switch cost is > > quite > > > > high, and that’s just one less PR that the second “cross” committer > > could > > > > have reviewed somewhere else in that time. Besides, current setup > that > > we > > > > have (with no cross +1 from another committer required) works quite > > well > > > > and I do not feel that’s causing troubles. On the other hand > reviewing > > > > bottleneck is. > > > > >>> > > > > >>> 2. > > > > >>> > > > > >>>> I think a committer should know when to ask another committer > for > > > > feedback or not. > > > > >>> I’m missing this stated somewhere clearly. If we are stating > that a > > > > single committers +1 is good enough for code review, with 0 hours > delay > > > (de > > > > facto the current state), we should also write down that this is > > subject > > > to > > > > the best judgement of the committer to respect the components > expertise > > > and > > > > ongoing development plans (also the de facto current state). > > > > >>> > > > > >>> 3. > > > > >>> > > > > >>> Minimum length of 3 days for FLIP I think currently might be > > > > problematic/too quick and can lead to problems if respected to the > > > letter. > > > > Again I think it depends highly on whether the committers with > highest > > > > expertise in the affected components managed to respond or not. > > > > >>> > > > > >>> Piotrek > > > > >>> > > > > >>>> On 12 Jul 2019, at 09:42, Chesnay Schepler <ches...@apache.org> > > > > wrote: > > > > >>>> > > > > >>>> I'm wondering whether we shouldn't first write down Bylaws that > > > > reflect the current state, and then have separate discussions for > > > > individual amendments. My gut feeling is that this discussion will > > > quickly > > > > become a chaotic mess with plenty points being discussed at once. > > > > >>>> > > > > >>>> On 11/07/2019 20:03, Bowen Li wrote: > > > > >>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket Qin < > > becket....@gmail.com> > > > > wrote: > > > > >>>>> > > > > >>>>>> Thanks everyone for all the comments and feedback. Please see > > the > > > > replies > > > > >>>>>> below: > > > > >>>>>> > > > > >>>>>> -------------------------------- > > > > >>>>>> Re: Konstantin > > > > >>>>>> > > > > >>>>>>> * In addition to a simple "Code Change" we could also add a > row > > > > for "Code > > > > >>>>>>> Change requiring a FLIP" with a reference to the FLIP process > > > > page. A > > > > >>>>>> FLIP > > > > >>>>>>> will have/does have different rules for approvals, etc. > > > > >>>>>> Good point. Just added the entry. > > > > >>>>>> > > > > >>>>>> ------------------------------- > > > > >>>>>> Re: Konstantin > > > > >>>>>> > > > > >>>>>>> * For "Code Change" the draft currently requires "one +1 > from a > > > > committer > > > > >>>>>>> who has not authored the patch followed by a Lazy approval > (not > > > > counting > > > > >>>>>>> the vote of the contributor), moving to lazy majority if a -1 > > is > > > > >>>>>> received". > > > > >>>>>>> In my understanding this means, that a committer always > needs a > > > > review > > > > >>>>>> and > > > > >>>>>>> +1 from another committer. As far as I know this is currently > > not > > > > always > > > > >>>>>>> the case (often committer authors, contributor reviews & > +1s). > > > > >>>>>>> > > > > >>>>>> I think it is worth thinking about how we can make it easy to > > > > follow the > > > > >>>>>>> bylaws e.g. by having more Flink-specific Jira workflows and > > > ticket > > > > >>>>>> types + > > > > >>>>>>> corresponding permissions. While this is certainly "Step 2", > I > > > > believe, > > > > >>>>>> we > > > > >>>>>>> really need to make it as easy & transparent as possible, > > > > otherwise they > > > > >>>>>>> will be unintentionally broken. > > > > >>>>>> & Re: Till > > > > >>>>>> > > > > >>>>>>> For the case of a committer being the author and getting a +1 > > > from > > > > a > > > > >>>>>>> non-committer: I think a committer should know when to ask > > > another > > > > >>>>>>> committer for feedback or not. Hence, I would not enforce > that > > we > > > > >>>>>> strictly > > > > >>>>>>> need a +1 from a committer if the author is a committer but > of > > > > course > > > > >>>>>>> encourage it if capacities exist. > > > > >>>>>> I am with Robert and Aljoscha on this. > > > > >>>>>> > > > > >>>>>> I completely understand the concern here. TBH, in Kafka > > > occasionally > > > > >>>>>> trivial patches from committers are still merged without > > following > > > > the > > > > >>>>>> cross-review requirement, but it is rare. That said, I still > > think > > > > an > > > > >>>>>> additional committer's review makes sense due to the following > > > > reasons: > > > > >>>>>> 1. The bottom line here is that we need to make sure every > patch > > > is > > > > >>>>>> reviewed with a high quality. This is a little difficult to > > > > guarantee if > > > > >>>>>> the review comes from a contributor for many reasons. In some > > > > cases, a > > > > >>>>>> contributor may not have enough knowledge about the project to > > > make > > > > a good > > > > >>>>>> judgement. Also sometimes the contributors are more eagerly to > > > get a > > > > >>>>>> particular issue fixed, so they are willing to lower the > review > > > bar. > > > > >>>>>> 2. One byproduct of such cross review among committers, which > I > > > > personally > > > > >>>>>> feel useful, is that it helps gradually form consistent design > > > > principles > > > > >>>>>> and code style. This is because the committers will know how > the > > > > other > > > > >>>>>> committers are writing code and learn from each other. So they > > > tend > > > > to > > > > >>>>>> reach some tacit understanding on how things should be done in > > > > general. > > > > >>>>>> > > > > >>>>>> Another way to think about this is to consider the following > two > > > > scenarios: > > > > >>>>>> 1. Reviewing a committer's patch takes a lot of iterations. > Then > > > > the patch > > > > >>>>>> needs to be reviewed even if it takes time because there are > > > things > > > > >>>>>> actually needs to be clarified / changed. > > > > >>>>>> 2. Reviewing a committer's patch is very smooth and quick, so > > the > > > > patch is > > > > >>>>>> merged soon. Then reviewing such a patch does not take much > > time. > > > > >>>>>> > > > > >>>>>> Letting another committer review the patch from a committer > > falls > > > > either in > > > > >>>>>> case 1 or case 2. The best option here is to review the patch > > > > because > > > > >>>>>> If it is case 1, the patch actually needs to be reviewed. > > > > >>>>>> If it is case 2, the review should not take much time anyways. > > > > >>>>>> > > > > >>>>>> In the contrast, we will risk encounter case 1 if we skip the > > > > cross-review. > > > > >>>>>> > > > > >>>>>> ------------------------ > > > > >>>>>> Re: Robert > > > > >>>>>> > > > > >>>>>> I replied to your comments in the wiki and made the following > > > > modifications > > > > >>>>>> to resolve some of your comments: > > > > >>>>>> 1. Added a release manager role section. > > > > >>>>>> 2. changed the name of "lazy consensus" to "consensus" to > align > > > with > > > > >>>>>> general definition of Apache glossary and other projects. > > > > >>>>>> 3. review board -> pull request > > > > >>>>>> > > > > >>>>>> ------------------------- > > > > >>>>>> Re: Chesnay > > > > >>>>>> > > > > >>>>>> The emeritus stuff seems like unnecessary noise. > > > > >>>>>> As Till mentioned, this is to make sure 2/3 majority is still > > > > feasible in > > > > >>>>>> practice. > > > > >>>>>> > > > > >>>>>> There's a bunch of subtle changes in the draft compared to > > > existing > > > > >>>>>>> "conventions"; we should find a way to highlight these and > > > discuss > > > > them > > > > >>>>>>> one by one. > > > > >>>>>> That is a good suggestion. I am not familiar enough with the > > > > current Flink > > > > >>>>>> convention. Will you help on this? I saw you commented on some > > > part > > > > in the > > > > >>>>>> wiki. Are those complete? > > > > >>>>>> > > > > >>>>>> -------------------------- > > > > >>>>>> Re: Aljoscha > > > > >>>>>> > > > > >>>>>> How different is this from the Kafka bylaws? I’m asking > because > > I > > > > quite > > > > >>>>>>> like them and wouldn’t mind essentially adopting the Kafka > > > bylaws. > > > > I > > > > >>>>>> mean, > > > > >>>>>>> it’s open source, and we don’t have to try to re-invent the > > wheel > > > > here. > > > > >>>>>> Ha, you got me on this. The first version of the draft was > > almost > > > > identical > > > > >>>>>> to Kafka. But Robert has already caught a few inconsistent > > places. > > > > So it > > > > >>>>>> might still worth going through it to make sure we truly agree > > on > > > > them. > > > > >>>>>> Otherwise we may end up modifying them shortly after adoption. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Thanks again folks, for all the valuable feedback. These are > > great > > > > >>>>>> discussion. > > > > >>>>>> > > > > >>>>>> Jiangjie (Becket) Qin > > > > >>>>>> > > > > >>>>>> On Thu, Jul 11, 2019 at 9:55 PM Aljoscha Krettek < > > > > aljos...@apache.org> > > > > >>>>>> wrote: > > > > >>>>>> > > > > >>>>>>> Big +1 > > > > >>>>>>> > > > > >>>>>>> How different is this from the Kafka bylaws? I’m asking > > because I > > > > quite > > > > >>>>>>> like them and wouldn’t mind essentially adopting the Kafka > > > bylaws. > > > > I > > > > >>>>>> mean, > > > > >>>>>>> it’s open source, and we don’t have to try to re-invent the > > wheel > > > > here. > > > > >>>>>>> > > > > >>>>>>> I think it’s worthwhile to discuss the “committer +1” > > > requirement. > > > > We > > > > >>>>>>> don’t usually have that now but I would actually be in favour > > of > > > > >>>>>> requiring > > > > >>>>>>> it, although it might make stuff more complicated. > > > > >>>>>>> > > > > >>>>>>> Aljoscha > > > > >>>>>>> > > > > >>>>>>>> On 11. Jul 2019, at 15:31, Till Rohrmann < > > trohrm...@apache.org> > > > > wrote: > > > > >>>>>>>> > > > > >>>>>>>> Thanks a lot for creating this draft Becket. > > > > >>>>>>>> > > > > >>>>>>>> I think without the notion of emeritus (or active vs. > > inactive), > > > > it > > > > >>>>>> won't > > > > >>>>>>>> be possible to have a 2/3 majority vote because we already > > have > > > > too > > > > >>>>>> many > > > > >>>>>>>> inactive PMCs/committers. > > > > >>>>>>>> > > > > >>>>>>>> For the case of a committer being the author and getting a > +1 > > > > from a > > > > >>>>>>>> non-committer: I think a committer should know when to ask > > > another > > > > >>>>>>>> committer for feedback or not. Hence, I would not enforce > that > > > we > > > > >>>>>>> strictly > > > > >>>>>>>> need a +1 from a committer if the author is a committer but > of > > > > course > > > > >>>>>>>> encourage it if capacities exist. > > > > >>>>>>>> > > > > >>>>>>>> Cheers, > > > > >>>>>>>> Till > > > > >>>>>>>> > > > > >>>>>>>> On Thu, Jul 11, 2019 at 3:08 PM Chesnay Schepler < > > > > ches...@apache.org> > > > > >>>>>>> wrote: > > > > >>>>>>>>> The emeritus stuff seems like unnecessary noise. > > > > >>>>>>>>> > > > > >>>>>>>>> There's a bunch of subtle changes in the draft compared to > > > > existing > > > > >>>>>>>>> "conventions"; we should find a way to highlight these and > > > > discuss > > > > >>>>>> them > > > > >>>>>>>>> one by one. > > > > >>>>>>>>> > > > > >>>>>>>>> On 11/07/2019 14:29, Robert Metzger wrote: > > > > >>>>>>>>>> Thank you Becket for kicking off this discussion and > > creating > > > a > > > > draft > > > > >>>>>>> in > > > > >>>>>>>>>> the Wiki. > > > > >>>>>>>>>> > > > > >>>>>>>>>> I left some comments in the wiki. > > > > >>>>>>>>>> > > > > >>>>>>>>>> In my understanding this means, that a committer always > > needs > > > a > > > > >>>>>> review > > > > >>>>>>>>> and > > > > >>>>>>>>>>> +1 from another committer. As far as I know this is > > currently > > > > not > > > > >>>>>>> always > > > > >>>>>>>>>>> the case (often committer authors, contributor reviews & > > > +1s). > > > > >>>>>>>>>> I would agree to add such a bylaw, if we had cases in the > > past > > > > where > > > > >>>>>>> code > > > > >>>>>>>>>> was not sufficiently reviewed AND we believe that we have > > > enough > > > > >>>>>>> capacity > > > > >>>>>>>>>> to ensure a separate committer's approval. > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> On Thu, Jul 11, 2019 at 9:49 AM Konstantin Knauf < > > > > >>>>>>>>> konstan...@ververica.com> > > > > >>>>>>>>>> wrote: > > > > >>>>>>>>>> > > > > >>>>>>>>>>> Hi all, > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> thanks a lot for driving this, Becket. I have two remarks > > > > regarding > > > > >>>>>>> the > > > > >>>>>>>>>>> "Actions" section: > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> * In addition to a simple "Code Change" we could also > add a > > > > row for > > > > >>>>>>>>> "Code > > > > >>>>>>>>>>> Change requiring a FLIP" with a reference to the FLIP > > process > > > > page. > > > > >>>>>> A > > > > >>>>>>>>> FLIP > > > > >>>>>>>>>>> will have/does have different rules for approvals, etc. > > > > >>>>>>>>>>> * For "Code Change" the draft currently requires "one +1 > > > from a > > > > >>>>>>>>> committer > > > > >>>>>>>>>>> who has not authored the patch followed by a Lazy > approval > > > (not > > > > >>>>>>> counting > > > > >>>>>>>>>>> the vote of the contributor), moving to lazy majority if > a > > -1 > > > > is > > > > >>>>>>>>> received". > > > > >>>>>>>>>>> In my understanding this means, that a committer always > > > needs a > > > > >>>>>> review > > > > >>>>>>>>> and > > > > >>>>>>>>>>> +1 from another committer. As far as I know this is > > currently > > > > not > > > > >>>>>>> always > > > > >>>>>>>>>>> the case (often committer authors, contributor reviews & > > > +1s). > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> I think it is worth thinking about how we can make it > easy > > to > > > > follow > > > > >>>>>>> the > > > > >>>>>>>>>>> bylaws e.g. by having more Flink-specific Jira workflows > > and > > > > ticket > > > > >>>>>>>>> types + > > > > >>>>>>>>>>> corresponding permissions. While this is certainly "Step > > 2", > > > I > > > > >>>>>>> believe, > > > > >>>>>>>>> we > > > > >>>>>>>>>>> really need to make it as easy & transparent as possible, > > > > otherwise > > > > >>>>>>> they > > > > >>>>>>>>>>> will be unintentionally broken. > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> Cheers and thanks, > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> Konstantin > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> On Thu, Jul 11, 2019 at 9:10 AM Becket Qin < > > > > becket....@gmail.com> > > > > >>>>>>>>> wrote: > > > > >>>>>>>>>>>> Hi all, > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> As it was raised in the FLIP process discussion thread > > [1], > > > > >>>>>> currently > > > > >>>>>>>>>>> Flink > > > > >>>>>>>>>>>> does not have official bylaws to govern the operation of > > the > > > > >>>>>> project. > > > > >>>>>>>>>>> Such > > > > >>>>>>>>>>>> bylaws are critical for the community to coordinate and > > > > contribute > > > > >>>>>>>>>>>> together. It is also the basis of other processes such > as > > > > FLIP. > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> I have drafted a Flink bylaws page and would like to > > start a > > > > >>>>>>> discussion > > > > >>>>>>>>>>>> thread on this. > > > > >>>>>>>>>>>> > > > > >>>>>> > > > > > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026 > > > > >>>>>>>>>>>> The bylaws will affect everyone in the community. It'll > be > > > > great to > > > > >>>>>>>>> hear > > > > >>>>>>>>>>>> your thoughts. > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> Thanks, > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> Jiangjie (Becket) Qin > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> [1] > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>> > > > > > > > > > > http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none > > > > >>>>>>>>>>> -- > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> Konstantin Knauf | Solutions Architect > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> +49 160 91394525 > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> Planned Absences: 10.08.2019 - 31.08.2019, 05.09. - > > > 06.09.2010 > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> -- > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, > > Germany > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> -- > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> Ververica GmbH > > > > >>>>>>>>>>> Registered at Amtsgericht Charlottenburg: HRB 158244 B > > > > >>>>>>>>>>> Managing Directors: Dr. Kostas Tzoumas, Dr. Stephan Ewen > > > > >>>>>>>>>>> > > > > > > > > > > > > > >
