Re: [VOTE] Migrate to sponsored Travis account

[Chesnay Schepler]

I have a prototype ready and will now commence a real world test. I will 
point it apache/flink and mirror it into a ververica controlled repo to 
start Travis runs.


Once the run is finished the bot will comment on the PR with the results.

This runs in addition to our existing CI.

On 04/07/2019 14:06, Chesnay Schepler wrote:
Note that the Flinkbot approach isn't that trivial either; we can't 
_just_ trigger builds for a branch in the apache repo, but would first 
have to clone the branch/pr into a separate repository (that is owned 
by the github account that the travis account would be tied to).


One roadblock after the next showing up...

On 04/07/2019 11:59, Chesnay Schepler wrote:

Small update with mostly bad news:

INFRA doesn't know whether it is possible, and referred my to Travis 
support.
They did point out that it could be problematic in regards to 
read/write permissions for the repository.


From my own findings /so far/ with a test repo/organization, it does 
not appear possible to configure the Travis account used for a 
specific repository.


So yeah, if we go down this route we may have to pimp the Flinkbot to 
trigger builds through the Travis REST API.


On 04/07/2019 10:46, Chesnay Schepler 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 
mailto: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
    > have also reported similar observations. So we need to evaluate
    how the
    > large total build time came from - if 1) your number and 2) our
    > observations from three locations that cover pretty much a full
    day, are
    > all true, I **guess** one reason can be that - highly likely the
    extra
    > build time came from weekends when other Apache projects may be
    idle and
    > Flink just drains hard its congested queue.
    >
    > Please be aware of that we're not complaining about the lack of
    resources
    > in general, I'm complaining about the lack of **stable, 
dedicated**

    > resources. An example for the latter one is, currently even if
    no build is
    > in Flink's queue and I submit a request to be the queue head 
in PST

    > morning, my build won't even start in 6-8+h. That is an absurd
    amount of
    > waiting time.
    >
    > That's saying, if ASF 

Re: [VOTE] Migrate to sponsored Travis account

[JingsongLee]

+1 for the migration

Best, JingsongLee


--
From:Jark Wu 
Send Time:2019年7月5日(星期五) 10:35
To:dev 
Cc:private ; Bowen Li 
Subject:Re: [VOTE] Migrate to sponsored Travis account

+1 for the migration and great thanks to Chesnay and Bowen for pushing this!

Cheers,
Jark

On Fri, 5 Jul 2019 at 09:34, Congxian Qiu  wrote:

> +1 for the migration.
>
> Best,
> Congxian
>
>
> Hequn Cheng  于2019年7月4日周四 下午9:42写道：
>
> > +1.
> >
> > And thanks a lot to Chesnay for pushing this.
> >
> > Best, Hequn
> >
> > On Thu, Jul 4, 2019 at 8:07 PM Chesnay Schepler 
> > wrote:
> >
> > > Note that the Flinkbot approach isn't that trivial either; we can't
> > > _just_ trigger builds for a branch in the apache repo, but would first
> > > have to clone the branch/pr into a separate repository (that is owned
> by
> > > the github account that the travis account would be tied to).
> > >
> > > One roadblock after the next showing up...
> > >
> > > On 04/07/2019 11:59, Chesnay Schepler wrote:
> > > > Small update with mostly bad news:
> > > >
> > > > INFRA doesn't know whether it is possible, and referred my to Travis
> > > > support.
> > > > They did point out that it could be problematic in regards to
> > > > read/write permissions for the repository.
> > > >
> > > > From my own findings /so far/ with a test repo/organization, it does
> > > > not appear possible to configure the Travis account used for a
> > > > specific repository.
> > > >
> > > > So yeah, if we go down this route we may have to pimp the Flinkbot to
> > > > trigger builds through the Travis REST API.
> > > >
> > > > On 04/07/2019 10:46, Chesnay Schepler 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 

Re: [VOTE] Migrate to sponsored Travis account

[Yun Tang]

I noticed that switching to a separate Travis account to run CI is actually 
impossible from what https://issues.apache.org/jira/browse/INFRA-18703 said. 
Hope another option from Chesnay to speed up the CI progress would work soon.


Best
Yun Tang

From: Jark Wu 
Sent: Friday, July 5, 2019 10:34
To: dev
Cc: priv...@flink.apache.org; Bowen Li
Subject: Re: [VOTE] Migrate to sponsored Travis account

+1 for the migration and great thanks to Chesnay and Bowen for pushing this!

Cheers,
Jark

On Fri, 5 Jul 2019 at 09:34, Congxian Qiu  wrote:

> +1 for the migration.
>
> Best,
> Congxian
>
>
> Hequn Cheng  于2019年7月4日周四 下午9:42写道：
>
> > +1.
> >
> > And thanks a lot to Chesnay for pushing this.
> >
> > Best, Hequn
> >
> > On Thu, Jul 4, 2019 at 8:07 PM Chesnay Schepler 
> > wrote:
> >
> > > Note that the Flinkbot approach isn't that trivial either; we can't
> > > _just_ trigger builds for a branch in the apache repo, but would first
> > > have to clone the branch/pr into a separate repository (that is owned
> by
> > > the github account that the travis account would be tied to).
> > >
> > > One roadblock after the next showing up...
> > >
> > > On 04/07/2019 11:59, Chesnay Schepler wrote:
> > > > Small update with mostly bad news:
> > > >
> > > > INFRA doesn't know whether it is possible, and referred my to Travis
> > > > support.
> > > > They did point out that it could be problematic in regards to
> > > > read/write permissions for the repository.
> > > >
> > > > From my own findings /so far/ with a test repo/organization, it does
> > > > not appear possible to configure the Travis account used for a
> > > > specific repository.
> > > >
> > > > So yeah, if we go down this route we may have to pimp the Flinkbot to
> > > > trigger builds through the Travis REST API.
> > > >
> > > > On 04/07/2019 10:46, Chesnay Schepler wrote:
> > > >> I've raised a JIRA
> > > >> <https://issues.apache.org/jira/browse/INFRA-18703>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]
> > > >>>
> > > &

Re: [VOTE] Migrate to sponsored Travis account

[Jark Wu]

+1 for the migration and great thanks to Chesnay and Bowen for pushing this!

Cheers,
Jark

On Fri, 5 Jul 2019 at 09:34, Congxian Qiu  wrote:

> +1 for the migration.
>
> Best,
> Congxian
>
>
> Hequn Cheng  于2019年7月4日周四 下午9:42写道：
>
> > +1.
> >
> > And thanks a lot to Chesnay for pushing this.
> >
> > Best, Hequn
> >
> > On Thu, Jul 4, 2019 at 8:07 PM Chesnay Schepler 
> > wrote:
> >
> > > Note that the Flinkbot approach isn't that trivial either; we can't
> > > _just_ trigger builds for a branch in the apache repo, but would first
> > > have to clone the branch/pr into a separate repository (that is owned
> by
> > > the github account that the travis account would be tied to).
> > >
> > > One roadblock after the next showing up...
> > >
> > > On 04/07/2019 11:59, Chesnay Schepler wrote:
> > > > Small update with mostly bad news:
> > > >
> > > > INFRA doesn't know whether it is possible, and referred my to Travis
> > > > support.
> > > > They did point out that it could be problematic in regards to
> > > > read/write permissions for the repository.
> > > >
> > > > From my own findings /so far/ with a test repo/organization, it does
> > > > not appear possible to configure the Travis account used for a
> > > > specific repository.
> > > >
> > > > So yeah, if we go down this route we may have to pimp the Flinkbot to
> > > > trigger builds through the Travis REST API.
> > > >
> > > > On 04/07/2019 10:46, Chesnay Schepler 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

Re: [VOTE] Migrate to sponsored Travis account

[Congxian Qiu]

+1 for the migration.

Best,
Congxian


Hequn Cheng  于2019年7月4日周四 下午9:42写道：

> +1.
>
> And thanks a lot to Chesnay for pushing this.
>
> Best, Hequn
>
> On Thu, Jul 4, 2019 at 8:07 PM Chesnay Schepler 
> wrote:
>
> > Note that the Flinkbot approach isn't that trivial either; we can't
> > _just_ trigger builds for a branch in the apache repo, but would first
> > have to clone the branch/pr into a separate repository (that is owned by
> > the github account that the travis account would be tied to).
> >
> > One roadblock after the next showing up...
> >
> > On 04/07/2019 11:59, Chesnay Schepler wrote:
> > > Small update with mostly bad news:
> > >
> > > INFRA doesn't know whether it is possible, and referred my to Travis
> > > support.
> > > They did point out that it could be problematic in regards to
> > > read/write permissions for the repository.
> > >
> > > From my own findings /so far/ with a test repo/organization, it does
> > > not appear possible to configure the Travis account used for a
> > > specific repository.
> > >
> > > So yeah, if we go down this route we may have to pimp the Flinkbot to
> > > trigger builds through the Travis REST API.
> > >
> > > On 04/07/2019 10:46, Chesnay Schepler 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  > >>> > 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
> > >>> > have also reported similar observations. So we need to evaluate
> > >>> how the
> > >>> > large total build time came from - if 1) your number and 2) our
> > >>> > observations from three locations that cover pretty much a full
> > >>> day, are
> > >>> > all true, I **guess** one reason can be that - highly likely
> the
> > >>> extra
> > 

Re: [VOTE] Migrate to sponsored Travis account

[Bowen Li]

+1 on approval of the migration to our own Travis account. The foreseeable
benefits of the whole community's productivity and iteration speed would be
significant!

I think using Flinkbot or Travis REST API would be an implementation
details. Once we determine the overall direction, details can be figured
out.

Good news is that, upon my research on how Arrow and Spark integrate their
own in-house CI services with github repo, they are both using bots with
Github API. See a typical PR check for those projects at [1] and [2]. Thus,
we are **not alone** on this path.

Specifically for Apache Arrow, they have 'Ursabot', similar to our
Flinkbot, as I shared the link in the discussion. [3] lays out how Usrabot
works and integrates with Github API to trigger build. I think their
documentations is a bit outdated though - the doc says it cannot report
back build status to github, but from [1] we can see that the build status
are actually reported.

@Chesnay thanks for taking actions on this. Though I don't have access to
settings of Flink's github repo, I will continue to help push this
initiative in whichever way I can. Wes and Krisztián from Arrow are also
very friendly and helpful, and I can connect you to them to learn their
experience.

[1] https://github.com/apache/arrow/pull/4809
[2] https://github.com/apache/spark/pull/25053
[3] https://github.com/ursa-labs/ursabot#driving-ursabot


On Thu, Jul 4, 2019 at 6:42 AM Hequn Cheng  wrote:

> +1.
>
> And thanks a lot to Chesnay for pushing this.
>
> Best, Hequn
>
> On Thu, Jul 4, 2019 at 8:07 PM Chesnay Schepler 
> wrote:
>
>> Note that the Flinkbot approach isn't that trivial either; we can't
>> _just_ trigger builds for a branch in the apache repo, but would first
>> have to clone the branch/pr into a separate repository (that is owned by
>> the github account that the travis account would be tied to).
>>
>> One roadblock after the next showing up...
>>
>> On 04/07/2019 11:59, Chesnay Schepler wrote:
>> > Small update with mostly bad news:
>> >
>> > INFRA doesn't know whether it is possible, and referred my to Travis
>> > support.
>> > They did point out that it could be problematic in regards to
>> > read/write permissions for the repository.
>> >
>> > From my own findings /so far/ with a test repo/organization, it does
>> > not appear possible to configure the Travis account used for a
>> > specific repository.
>> >
>> > So yeah, if we go down this route we may have to pimp the Flinkbot to
>> > trigger builds through the Travis REST API.
>> >
>> > On 04/07/2019 10:46, Chesnay Schepler 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 > >>> > wrote:
>> >>>
>> >>> Are they using their 

Re: [VOTE] Migrate to sponsored Travis account

[Hequn Cheng]

+1.

And thanks a lot to Chesnay for pushing this.

Best, Hequn

On Thu, Jul 4, 2019 at 8:07 PM Chesnay Schepler  wrote:

> Note that the Flinkbot approach isn't that trivial either; we can't
> _just_ trigger builds for a branch in the apache repo, but would first
> have to clone the branch/pr into a separate repository (that is owned by
> the github account that the travis account would be tied to).
>
> One roadblock after the next showing up...
>
> On 04/07/2019 11:59, Chesnay Schepler wrote:
> > Small update with mostly bad news:
> >
> > INFRA doesn't know whether it is possible, and referred my to Travis
> > support.
> > They did point out that it could be problematic in regards to
> > read/write permissions for the repository.
> >
> > From my own findings /so far/ with a test repo/organization, it does
> > not appear possible to configure the Travis account used for a
> > specific repository.
> >
> > So yeah, if we go down this route we may have to pimp the Flinkbot to
> > trigger builds through the Travis REST API.
> >
> > On 04/07/2019 10:46, Chesnay Schepler 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  >>> > 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
> >>> > have also reported similar observations. So we need to evaluate
> >>> how the
> >>> > large total build time came from - if 1) your number and 2) our
> >>> > observations from three locations that cover pretty much a full
> >>> day, are
> >>> > all true, I **guess** one reason can be that - highly likely the
> >>> extra
> >>> > build time came from weekends when other Apache projects may be
> >>> idle and
> >>> > Flink just drains hard its congested queue.
> >>> >
> >>> > Please be aware of that we're not complaining about the lack of
> >>> resources
> >>> > in general, I'm complaining about the lack of 

Re: [VOTE] Migrate to sponsored Travis account

[Chesnay Schepler]

Note that the Flinkbot approach isn't that trivial either; we can't 
_just_ trigger builds for a branch in the apache repo, but would first 
have to clone the branch/pr into a separate repository (that is owned by 
the github account that the travis account would be tied to).


One roadblock after the next showing up...

On 04/07/2019 11:59, Chesnay Schepler wrote:

Small update with mostly bad news:

INFRA doesn't know whether it is possible, and referred my to Travis 
support.
They did point out that it could be problematic in regards to 
read/write permissions for the repository.


From my own findings /so far/ with a test repo/organization, it does 
not appear possible to configure the Travis account used for a 
specific repository.


So yeah, if we go down this route we may have to pimp the Flinkbot to 
trigger builds through the Travis REST API.


On 04/07/2019 10:46, Chesnay Schepler 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 > 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
    > have also reported similar observations. So we need to evaluate
    how the
    > large total build time came from - if 1) your number and 2) our
    > observations from three locations that cover pretty much a full
    day, are
    > all true, I **guess** one reason can be that - highly likely the
    extra
    > build time came from weekends when other Apache projects may be
    idle and
    > Flink just drains hard its congested queue.
    >
    > Please be aware of that we're not complaining about the lack of
    resources
    > in general, I'm complaining about the lack of **stable, 
dedicated**

    > resources. An example for the latter one is, currently even if
    no build is
    > in Flink's queue and I submit a request to be the queue head 
in PST

    > morning, my build won't even start in 6-8+h. That is an absurd
    amount of
    > waiting time.
    >
    > That's saying, if ASF INFRA decides to adopt a quota system and
    grants
    > Flink five DEDICATED servers that runs all the time only for
    Flink, that'll
    > be PERFECT and can totally solve our problem now.
    >
    > Please be aware of that we're not complaining about the lack of
    resources
    > in general, I'm complaining about the 

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: [VOTE] Migrate to sponsored Travis account

[vino yang]

+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 
> >>> 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
> >>> have also reported similar observations. So we need to evaluate
> >>   how the
> >>> large total build time came from - if 1) your number and 2) our
> >>> observations from three locations that cover pretty much a full
> >>   day, are
> >>> all true, I **guess** one reason can be that - highly likely the
> >>   extra
> >>> 

Re: [VOTE] Migrate to sponsored Travis account

[Dian Fu]

+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 
>>> 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 > > 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
>>> have also reported similar observations. So we need to evaluate
>>   how the
>>> large total build time came from - if 1) your number and 2) our
>>> observations from three locations that cover pretty much a full
>>   day, are
>>> all true, I **guess** one reason can be that - highly likely the
>>   extra
>>> build time came from weekends when other Apache projects may be
>>   idle and
>>> Flink just drains hard its congested queue.
>>> 
>>> Please be aware of that we're not complaining about the lack of
>>   resources
>>> in general, I'm complaining about the lack of **stable, dedicated**
>>> 

Re: Re: [VOTE] Migrate to sponsored Travis account

[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 
>> 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 > >>> > 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
>>  have also reported similar observations. So we need to evaluate
>> >>>how the
>>  large total build time came from - if 1) your number and 2) our
>>  observations from three locations that cover pretty much a full
>> >>>day, are
>>  all true, I **guess** one reason can be that - highly likely the
>> >>>extra
>>  build time came from weekends when other Apache projects may be
>> >>>idle and
>>  Flink just drains hard its congested queue.
>> 
>>  Please be aware of that we're not complaining about the lack of
>> >>>resources
>>  in general, I'm complaining about the lack of **stable, dedicated**
>>  resources. An example for the latter one is, currently even if
>> >>>no build is
>>  in Flink's queue and I submit a request to be the queue head in PST
>>  morning, my 

Re: [VOTE] Migrate to sponsored Travis account

[Chesnay Schepler]

Small update with mostly bad news:

INFRA doesn't know whether it is possible, and referred my to Travis 
support.
They did point out that it could be problematic in regards to read/write 
permissions for the repository.


From my own findings /so far/ with a test repo/organization, it does 
not appear possible to configure the Travis account used for a specific 
repository.


So yeah, if we go down this route we may have to pimp the Flinkbot to 
trigger builds through the Travis REST API.


On 04/07/2019 10:46, Chesnay Schepler 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 > 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
    > have also reported similar observations. So we need to evaluate
    how the
    > large total build time came from - if 1) your number and 2) our
    > observations from three locations that cover pretty much a full
    day, are
    > all true, I **guess** one reason can be that - highly likely the
    extra
    > build time came from weekends when other Apache projects may be
    idle and
    > Flink just drains hard its congested queue.
    >
    > Please be aware of that we're not complaining about the lack of
    resources
    > in general, I'm complaining about the lack of **stable, 
dedicated**

    > resources. An example for the latter one is, currently even if
    no build is
    > in Flink's queue and I submit a request to be the queue head in 
PST

    > morning, my build won't even start in 6-8+h. That is an absurd
    amount of
    > waiting time.
    >
    > That's saying, if ASF INFRA decides to adopt a quota system and
    grants
    > Flink five DEDICATED servers that runs all the time only for
    Flink, that'll
    > be PERFECT and can totally solve our problem now.
    >
    > Please be aware of that we're not complaining about the lack of
    resources
    > in general, I'm complaining about the lack of **stable, 
dedicated**

    > resources. An example for the latter one is, currently even if
    no build is
    > in Flink's queue and I submit a request to be the queue head in 
PST

    > morning, my build won't even start in 6-8+h. That is an absurd
    amount of
    > waiting time.
    >
    >
    > That's saying, if ASF INFRA decides to adopt a quota system 

Re: [VOTE] Migrate to sponsored Travis account

[Kurt Young]

+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 
> 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  >>> > 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
>  have also reported similar observations. So we need to evaluate
> >>>how the
>  large total build time came from - if 1) your number and 2) our
>  observations from three locations that cover pretty much a full
> >>>day, are
>  all true, I **guess** one reason can be that - highly likely the
> >>>extra
>  build time came from weekends when other Apache projects may be
> >>>idle and
>  Flink just drains hard its congested queue.
> 
>  Please be aware of that we're not complaining about the lack of
> >>>resources
>  in general, I'm complaining about the lack of **stable, dedicated**
>  resources. An example for the latter one is, currently even if
> >>>no build is
>  in Flink's queue and I submit a request to be the queue head in PST
>  morning, my build won't even start in 6-8+h. That is an absurd
> >>>amount of
>  waiting time.
> 
>  That's saying, if ASF INFRA decides to adopt a quota system and
> >>>grants
>  Flink five DEDICATED servers that runs all the time only for
> >>>Flink, that'll
>  be PERFECT and can totally solve our problem now.
> 
>  Please be aware of that we're not complaining about the lack of
> >>>resources
>  in general, I'm complaining about the lack of **stable, 

Re: [VOTE] Migrate to sponsored Travis account

[Aljoscha Krettek]

+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  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 >> > 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
 have also reported similar observations. So we need to evaluate
>>>how the
 large total build time came from - if 1) your number and 2) our
 observations from three locations that cover pretty much a full
>>>day, are
 all true, I **guess** one reason can be that - highly likely the
>>>extra
 build time came from weekends when other Apache projects may be
>>>idle and
 Flink just drains hard its congested queue.
 
 Please be aware of that we're not complaining about the lack of
>>>resources
 in general, I'm complaining about the lack of **stable, dedicated**
 resources. An example for the latter one is, currently even if
>>>no build is
 in Flink's queue and I submit a request to be the queue head in PST
 morning, my build won't even start in 6-8+h. That is an absurd
>>>amount of
 waiting time.
 
 That's saying, if ASF INFRA decides to adopt a quota system and
>>>grants
 Flink five DEDICATED servers that runs all the time only for
>>>Flink, that'll
 be PERFECT and can totally solve our problem now.
 
 Please be aware of that we're not complaining about the lack of
>>>resources
 in general, I'm complaining about the lack of **stable, dedicated**
 resources. An example for the latter one is, currently even if
>>>no build is
 in Flink's queue and I submit a request to be the queue head in PST
 morning, my build won't even start in 6-8+h. That is an absurd
>>>amount of
 waiting time.
 
 
 That's saying, if ASF INFRA decides to adopt a quota 

Re: [VOTE] Migrate to sponsored Travis account

[Stephan Ewen]

+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  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  > > 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
> > > have also reported similar observations. So we need to evaluate
> > how the
> > > large total build time came from - if 1) your number and 2) our
> > > observations from three locations that cover pretty much a full
> > day, are
> > > all true, I **guess** one reason can be that - highly likely the
> > extra
> > > build time came from weekends when other Apache projects may be
> > idle and
> > > Flink just drains hard its congested queue.
> > >
> > > Please be aware of that we're not complaining about the lack of
> > resources
> > > in general, I'm complaining about the lack of **stable, dedicated**
> > > resources. An example for the latter one is, currently even if
> > no build is
> > > in Flink's queue and I submit a request to be the queue head in PST
> > > morning, my build won't even start in 6-8+h. That is an absurd
> > amount of
> > > waiting time.
> > >
> > > That's saying, if ASF INFRA decides to adopt a quota system and
> > grants
> > > Flink five DEDICATED servers that runs all the time only for
> > Flink, that'll
> > > be PERFECT and can totally solve our problem now.
> > >
> > > Please be aware of that we're not complaining about the lack of
> > resources
> > > in general, I'm complaining about the lack of **stable, dedicated**
> > > resources. An example for the latter one is, currently even if
> > no build is
> > > in Flink's queue and I submit a request to be the queue head in PST
> > > morning, my build won't even start in 6-8+h. That is an absurd
> > amount of
> > > waiting time.
> > >
> >