Re: [VOTE] Migrate to sponsored Travis account

[Xu Forward]

+1

vino yang  于2019年7月4日周四 下午7:55写道：

> +1
>
> Dian Fu  于2019年7月4日周四 下午7:09写道：
>
> > +1. Thanks Chesnay and Bowen for pushing this forward.
> >
> > Regards,
> > Dian
> >
> > > 在 2019年7月4日，下午6:28，zhijiang  写道：
> > >
> > > +1 and thanks for Chesnay' work on this.
> > >
> > > Best,
> > > Zhijiang
> > >
> > > --
> > > From:Haibo Sun 
> > > Send Time:2019年7月4日(星期四) 18:21
> > > To:dev 
> > > Cc:priv...@flink.apache.org 
> > > Subject:Re:Re: [VOTE] Migrate to sponsored Travis account
> > >
> > > +1. Thank Chesnay for pushing this forward.
> > >
> > > Best,
> > > Haibo
> > >
> > >
> > > At 2019-07-04 17:58:28, "Kurt Young"  wrote:
> > >> +1 and great thanks Chesnay for pushing this.
> > >>
> > >> Best,
> > >> Kurt
> > >>
> > >>
> > >> On Thu, Jul 4, 2019 at 5:44 PM Aljoscha Krettek 
> > wrote:
> > >>
> > >>> +1
> > >>>
> > >>> Aljoscha
> > >>>
> >  On 4. Jul 2019, at 11:09, Stephan Ewen  wrote:
> > 
> >  +1 to move to a private Travis account.
> > 
> >  I can confirm that Ververica will sponsor a Travis CI plan that is
> >  equivalent or a bit higher than the previous ASF quota (10
> concurrent
> > >>> build
> >  queues)
> > 
> >  Best,
> >  Stephan
> > 
> >  On Thu, Jul 4, 2019 at 10:46 AM Chesnay Schepler <
> ches...@apache.org>
> > >>> wrote:
> > 
> > > I've raised a JIRA
> > > with INFRA to
> > >>> inquire
> > > whether it would be possible to switch to a different Travis
> account,
> > > and if so what steps would need to be taken.
> > > We need a proper confirmation from INFRA since we are not in full
> > > control of the flink repository (for example, we cannot access the
> > > settings page).
> > >
> > > If this is indeed possible, Ververica is willing sponsor a Travis
> > > account for the Flink project.
> > > This would provide us with more than enough resources than we need.
> > >
> > > Since this makes the project more reliant on resources provided by
> > > external companies I would like to vote on this.
> > >
> > > Please vote on this proposal, as follows:
> > > [ ] +1, Approve the migration to a Ververica-sponsored Travis
> > account,
> > > provided that INFRA approves
> > > [ ] -1, Do not approach the migration to a Ververica-sponsored
> Travis
> > > account
> > >
> > > The vote will be open for at least 24h, and until we have
> > confirmation
> > > from INFRA. The voting period may be shorter than the usual 3 days
> > since
> > > our current is effectively not working.
> > >
> > > On 04/07/2019 06:51, Bowen Li wrote:
> > >> Re: > Are they using their own Travis CI pool, or did the switch
> to
> > an
> > >> entirely different CI service?
> > >>
> > >> I reached out to Wes and Krisztián from Apache Arrow PMC. They are
> > >> currently moving away from ASF's Travis to their own in-house
> metal
> > >> machines at [1] with custom CI application at [2]. They've seen
> > >> significant improvement w.r.t both much higher performance and
> > >> basically no resource waiting time, "night-and-day" difference
> > quoting
> > >> Wes.
> > >>
> > >> Re: > If we can just switch to our own Travis pool, just for our
> > >> project, then this might be something we can do fairly quickly?
> > >>
> > >> I believe so, according to [3] and [4]
> > >>
> > >>
> > >> [1] https://ci.ursalabs.org/ 
> > >> [2] https://github.com/ursa-labs/ursabot
> > >> [3]
> > >>
> > >>>
> > https://docs.travis-ci.com/user/migrate/open-source-repository-migration
> > >> [4]
> > >>> https://docs.travis-ci.com/user/migrate/open-source-on-travis-ci-com
> > >>
> > >>
> > >>
> > >> On Wed, Jul 3, 2019 at 12:01 AM Chesnay Schepler <
> > ches...@apache.org
> > >> > wrote:
> > >>
> > >>   Are they using their own Travis CI pool, or did the switch to an
> > >>   entirely different CI service?
> > >>
> > >>   If we can just switch to our own Travis pool, just for our
> > >>   project, then
> > >>   this might be something we can do fairly quickly?
> > >>
> > >>   On 03/07/2019 05:55, Bowen Li wrote:
> > >>> I responded in the INFRA ticket [1] that I believe they are
> > >>   using a wrong
> > >>> metric against Flink and the total build time is a completely
> > >>   different
> > >>> thing than guaranteed build capacity.
> > >>>
> > >>> My response:
> > >>>
> > >>> "As mentioned above, since I started to pay attention to Flink's
> > >>   build
> > >>> queue a few tens of days ago, I'm in Seattle and I saw no build
> > >>   was kicking
> > >>> off in PST daytime in weekdays for Flink. Our teammates in China
> > >>   and Europe
> > >>> 

Re: [ANNOUNCE] Jiangjie (Becket) Qin has been added as a committer to the Flink project

[Xu Forward]

Congratulations Becket! Well deserved.


Cheers,

forward

Kurt Young  于2019年7月18日周四 下午4:20写道：

> Congrats Becket!
>
> Best,
> Kurt
>
>
> On Thu, Jul 18, 2019 at 4:12 PM JingsongLee  .invalid>
> wrote:
>
> > Congratulations Becket!
> >
> > Best, Jingsong Lee
> >
> >
> > --
> > From:Congxian Qiu 
> > Send Time:2019年7月18日(星期四) 16:09
> > To:dev@flink.apache.org 
> > Subject:Re: [ANNOUNCE] Jiangjie (Becket) Qin has been added as a
> committer
> > to the Flink project
> >
> > Congratulations Becket! Well deserved.
> >
> > Best,
> > Congxian
> >
> >
> > Jark Wu  于2019年7月18日周四 下午4:03写道：
> >
> > > Congratulations Becket! Well deserved.
> > >
> > > Cheers,
> > > Jark
> > >
> > > On Thu, 18 Jul 2019 at 15:56, Paul Lam  wrote:
> > >
> > > > Congrats Becket!
> > > >
> > > > Best,
> > > > Paul Lam
> > > >
> > > > > 在 2019年7月18日，15:41，Robert Metzger  写道：
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I'm excited to announce that Jiangjie (Becket) Qin just became a
> > Flink
> > > > > committer!
> > > > >
> > > > > Congratulations Becket!
> > > > >
> > > > > Best,
> > > > > Robert (on behalf of the Flink PMC)
> > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Setup a bui...@flink.apache.org mailing list for travis builds

[Xu Forward]

+1 ,Thanks jark for the proposal.
Best
Forward

Jark Wu  于2019年7月20日周六 下午12:14写道：

> Hi all,
>
> As far as I know, currently, email notifications of Travis builds for
> master branch are sent to the commit author when a build was just broken or
> still is broken. And there is no email notifications for CRON builds.
>
> Recently, we are suffering from compile errors for scala-2.12 and java-9
> which are only ran in CRON jobs. So I'm figuring out a way to get
> notifications of CRON builds (or all builds) to quick fix compile errors
> and failed cron tests.
>
> After reaching out to @Chesnay Schepler  (thanks for
> the helping), I know that we are using a Slack channel to receive all
> failed build notifications. However, IMO, email notification might be a
> better way than Slack channel to encourage more people to pay attention on
> the builds.
>
> So I'm here to propose to setup a bui...@flink.apache.org mailing list for
> receiving build notifications. I also find that Beam has such mailing list
> too[1]. After we have such a mailing list, we can integrate it to travis
> according to the travis doc[2].
>
> What do you think? Do we need a formal vote for this?
>
> Best and thanks,
> Jark
>
> [1]: https://beam.apache.org/community/contact-us/
> [2]:
>
> https://docs.travis-ci.com/user/notifications/#configuring-email-notifications
>
> <
> https://docs.travis-ci.com/user/notifications/#configuring-email-notifications
> >
>
> <
> https://docs.travis-ci.com/user/notifications/#configuring-email-notifications
> >
>

Re: [DISCUSS] Flink project bylaws

[Xu Forward]

Big +1 on this.


best

forward

Hequn Cheng  于2019年7月21日周日 下午1:30写道：

> 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  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 
> > 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  >
> > > 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  于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 (als

Re: [ANNOUNCE] Kete Young is now part of the Flink PMC

[Xu Forward]

Congratulations Kurt!


best

forward

Jark Wu  于2019年7月23日周二 下午5:49写道：

> Congratulations Kurt! Well deserved.
>
> Cheers,
> Jark
>
> On Tue, 23 Jul 2019 at 17:43, LakeShen  wrote:
>
> > Congratulations Kurt!
> >
> > Congxian Qiu  于2019年7月23日周二 下午5:37写道：
> >
> > > Congratulations Kurt!
> > > Best,
> > > Congxian
> > >
> > >
> > > Dian Fu  于2019年7月23日周二 下午5:36写道：
> > >
> > > > Congrats, Kurt!
> > > >
> > > > > 在 2019年7月23日，下午5:33，Zili Chen  写道：
> > > > >
> > > > > Congratulations Kurt!
> > > > >
> > > > > Best,
> > > > > tison.
> > > > >
> > > > >
> > > > > JingsongLee  于2019年7月23日周二
> > 下午5:29写道：
> > > > >
> > > > >> Congratulations Kurt!
> > > > >>
> > > > >> Best, Jingsong Lee
> > > > >>
> > > > >>
> > > > >> --
> > > > >> From:Robert Metzger 
> > > > >> Send Time:2019年7月23日(星期二) 17:24
> > > > >> To:dev 
> > > > >> Subject:[ANNOUNCE] Kete Young is now part of the Flink PMC
> > > > >>
> > > > >> Hi all,
> > > > >>
> > > > >> On behalf of the Flink PMC, I'm happy to announce that Kete Young
> is
> > > now
> > > > >> part of the Apache Flink Project Management Committee (PMC).
> > > > >>
> > > > >> Kete has been a committer since February 2017, working a lot on
> > Table
> > > > API /
> > > > >> SQL. He's currently co-managing the 1.9 release! Thanks a lot for
> > your
> > > > work
> > > > >> for Flink!
> > > > >>
> > > > >> Congratulations & Welcome Kurt!
> > > > >>
> > > > >> Best,
> > > > >> Robert
> > > > >>
> > > >
> > > >
> > >
> >
>

[DISCUSS] Support JSON functions in Flink SQL

[Xu Forward]

Hi everybody,

I'd like to kick off a discussion on Support JSON functions in Flink SQL.

The entire plan is divided into two steps:
1. Implement Support SQL 2016-2017 JSON functions in Flink SQL[1].
2. Implement non-Support SQL 2016-2017 JSON functions in Flink SQL, such as
JSON_TYPE in Mysql, JSON_LENGTH, etc. Very useful JSON functions.

Would love to hear your thoughts.

[1]
https://docs.google.com/document/d/1JfaFYIFOAY8P2pFhOYNCQ9RTzwF4l85_bnTvImOLKMk/edit#heading=h.76mb88ca6yjp

Best,
ForwardXu

Re: [DISCUSS] Support JSON functions in Flink SQL

[Xu Forward]

hi Danny Chan ,Thank you very much for your reply, your help can help me
further improve this discussion.
Best
forward

Danny Chan  于2019年9月4日周三 下午8:50写道：

> Thanks Xu Forward for bring up this topic, I think the JSON functions are
> very useful especially for those MySQL users.
>
> I saw that you have done some work within the Apache Calcite, that’s a
> good start, but this is one concern from me, Flink doesn’t support JSON
> type internal, so how to represent a JSON object in Flink maybe a key point
> we need to resolve. In Calcite, we use ANY type to represent as the JSON,
> but I don’t think it is the right way to go, maybe we can have a discussion
> here.
>
> Best,
> Danny Chan
> 在 2019年9月4日 +0800 PM8:34，Xu Forward ，写道：
> > Hi everybody,
> >
> > I'd like to kick off a discussion on Support JSON functions in Flink SQL.
> >
> > The entire plan is divided into two steps:
> > 1. Implement Support SQL 2016-2017 JSON functions in Flink SQL[1].
> > 2. Implement non-Support SQL 2016-2017 JSON functions in Flink SQL, such
> as
> > JSON_TYPE in Mysql, JSON_LENGTH, etc. Very useful JSON functions.
> >
> > Would love to hear your thoughts.
> >
> > [1]
> >
> https://docs.google.com/document/d/1JfaFYIFOAY8P2pFhOYNCQ9RTzwF4l85_bnTvImOLKMk/edit#heading=h.76mb88ca6yjp
> >
> > Best,
> > ForwardXu
>