Master not building and how to notice it faster in the future

[Robert Metzger]

Hi,

it seems that our master is currently not building. See:
https://travis-ci.org/apache/flink/jobs/47689754

We need to come up with a good solution to notify dev@flink when builds on
Travis are failing.

We also had unstable builds recently due to too short akka timeouts and it
took some time to realize that.

Usually, travis has a pretty good email notification system, but thats not
working for us because the repository is owned by the "apache" github user.
I think only users with admin permissions at "apache/flink" are notified by
email from travis.

There are certainly ways to fix this. Right now, the best approach is
probably setting up a REST 2 e-mail service somewhere which is mailing to
our dev@ list (
http://docs.travis-ci.com/user/notifications/#Webhook-notification).


Robert

[Ufuk Celebi-2]

On 20 Jan 2015, at 23:57, Robert Metzger <[hidden email]> wrote:

> There are certainly ways to fix this. Right now, the best approach is
> probably setting up a REST 2 e-mail service somewhere which is mailing to
> our dev@ list (
> http://docs.travis-ci.com/user/notifications/#Webhook-notification).

That sounds like a great idea. +1

I can look into it tomorrow. Are you aware of any web service/server we can use to decode the http request (e.g. something where we can run Sinatra as suggested by Travis)? We also need the GitHub user token of "apache". I will ask INFRA if I can't find anything related online.

[Robert Metzger]

I think its just a missing import.

Maybe we can use Google AppEngine for that. It seems that their free
offering is sufficient for our purpose:
https://cloud.google.com/pricing/#app-engine. It also allows sending emails.
I guess its hard to get the token for the "apache" user. Maybe there is is
a way to validate the authenticity of the requests differently.

On Wed, Jan 21, 2015 at 12:05 AM, Ufuk Celebi <[hidden email]> wrote:

>
> On 20 Jan 2015, at 23:57, Robert Metzger <[hidden email]> wrote:
>
> > There are certainly ways to fix this. Right now, the best approach is
> > probably setting up a REST 2 e-mail service somewhere which is mailing to
> > our dev@ list (
> > http://docs.travis-ci.com/user/notifications/#Webhook-notification).
>
> That sounds like a great idea. +1
>
> I can look into it tomorrow. Are you aware of any web service/server we
> can use to decode the http request (e.g. something where we can run Sinatra
> as suggested by Travis)? We also need the GitHub user token of "apache". I
> will ask INFRA if I can't find anything related online.

[Ufuk Celebi-2]

On 21 Jan 2015, at 00:19, Robert Metzger <[hidden email]> wrote:

> I think its just a missing import.

Yes.

> Maybe we can use Google AppEngine for that. It seems that their free
> offering is sufficient for our purpose:
> https://cloud.google.com/pricing/#app-engine. It also allows sending emails.
> I guess its hard to get the token for the "apache" user. Maybe there is is
> a way to validate the authenticity of the requests differently.

App engine sounds reasonable. :-)

[Max Michels]

Hi Robert,

I like your solution using Travis and Google App Engine. However, I
think there's a much simpler solution which can prevent commiters from
pushing not even compiling or test-failing code to the master in the
first place.

Commiters could simply install a git pre-push hook in their git
repository (this is merely placing a file named pre-push in
.git/hooks/). The pre-push hook would simply run "mvn clean package"
and would then fail to push to the master if maven does not report
success.

Such a precaution would save effort and time for everyone. You already
pointed out that not all eventualities are covered by the tests, so
this could be an additional measure to the Travis notifiction on the
dev mailing list.

Best regards,
Max

On Wed, Jan 21, 2015 at 12:30 AM, Ufuk Celebi <[hidden email]> wrote:

>
> On 21 Jan 2015, at 00:19, Robert Metzger <[hidden email]> wrote:
>
>> I think its just a missing import.
>
> Yes.
>
>> Maybe we can use Google AppEngine for that. It seems that their free
>> offering is sufficient for our purpose:
>> https://cloud.google.com/pricing/#app-engine. It also allows sending emails.
>> I guess its hard to get the token for the "apache" user. Maybe there is is
>> a way to validate the authenticity of the requests differently.
>
> App engine sounds reasonable. :-)

[Till Rohrmann]

I like both approaches because maven won't necessarily find all problems if
executed locally. Especially concurrency problems seem to occur more often
on travis than on my local machine.

Greets,

Till

On Wed, Jan 21, 2015 at 9:59 AM, Max Michels <[hidden email]> wrote:

> Hi Robert,
>
> I like your solution using Travis and Google App Engine. However, I
> think there's a much simpler solution which can prevent commiters from
> pushing not even compiling or test-failing code to the master in the
> first place.
>
> Commiters could simply install a git pre-push hook in their git
> repository (this is merely placing a file named pre-push in
> .git/hooks/). The pre-push hook would simply run "mvn clean package"
> and would then fail to push to the master if maven does not report
> success.
>
> Such a precaution would save effort and time for everyone. You already
> pointed out that not all eventualities are covered by the tests, so
> this could be an additional measure to the Travis notifiction on the
> dev mailing list.
>
> Best regards,
> Max
>
> On Wed, Jan 21, 2015 at 12:30 AM, Ufuk Celebi <[hidden email]> wrote:
> >
> > On 21 Jan 2015, at 00:19, Robert Metzger <[hidden email]> wrote:
> >
> >> I think its just a missing import.
> >
> > Yes.
> >
> >> Maybe we can use Google AppEngine for that. It seems that their free
> >> offering is sufficient for our purpose:
> >> https://cloud.google.com/pricing/#app-engine. It also allows sending
> emails.
> >> I guess its hard to get the token for the "apache" user. Maybe there is
> is
> >> a way to validate the authenticity of the requests differently.
> >
> > App engine sounds reasonable. :-)
>

[Ufuk Celebi-2]

On 21 Jan 2015, at 10:40, Till Rohrmann <[hidden email]> wrote:

> I like both approaches because maven won't necessarily find all problems if
> executed locally. Especially concurrency problems seem to occur more often
> on travis than on my local machine.

I agree with Till. Let's add a git hook to catch most of the local problems and the web hook for the Travis builds.

[Robert Metzger]

Is the git hook something we can control for everybody? I thought its more
like a personal thing everybody can set up if wanted?

I'm against enforcing something like this for every committer. I don't want
to wait for 15 minutes for pushing a typo fix to the documentation.


On Wed, Jan 21, 2015 at 11:36 AM, Ufuk Celebi <[hidden email]> wrote:

>
> On 21 Jan 2015, at 10:40, Till Rohrmann <[hidden email]> wrote:
>
> > I like both approaches because maven won't necessarily find all problems
> if
> > executed locally. Especially concurrency problems seem to occur more
> often
> > on travis than on my local machine.
>
> I agree with Till. Let's add a git hook to catch most of the local
> problems and the web hook for the Travis builds.

[Ufuk Celebi-2]

On 21 Jan 2015, at 11:40, Robert Metzger <[hidden email]> wrote:

> Is the git hook something we can control for everybody? I thought its more
> like a personal thing everybody can set up if wanted?
>
> I'm against enforcing something like this for every committer. I don't want
> to wait for 15 minutes for pushing a typo fix to the documentation.

Sorry, I didn't mean to have it in the repo. As long as we notice failing builds fast enough (aka email notification), it should be OK to keep it that way. As you said, every committer should decide this on her own. BTW You can always skip hooks with git push -n (--no-verify).

[Max Michels]

@Robert The pre-push hook only resides in your local repository. It
cannot be pushed. Thus, we cannot enforce this check but it certainly
helps to prevent mistakes. As Ufuk mentioned, you can then even skip
the check with the --no-verify option if you're really sure.

On Wed, Jan 21, 2015 at 11:45 AM, Ufuk Celebi <[hidden email]> wrote:

>
> On 21 Jan 2015, at 11:40, Robert Metzger <[hidden email]> wrote:
>
>> Is the git hook something we can control for everybody? I thought its more
>> like a personal thing everybody can set up if wanted?
>>
>> I'm against enforcing something like this for every committer. I don't want
>> to wait for 15 minutes for pushing a typo fix to the documentation.
>
> Sorry, I didn't mean to have it in the repo. As long as we notice failing builds fast enough (aka email notification), it should be OK to keep it that way. As you said, every committer should decide this on her own. BTW You can always skip hooks with git push -n (--no-verify).

[Max Michels]

I've created a pre-push hook that does what I described (and a bit
more). It does only enforce a check for the remote flink master branch
and doesn't disturb you on your pushes.

https://gist.github.com/mxm/4d1e26b901c66a682e4a

Just put the the file in the .git/hooks/ directory of your repository directory.

For example, if you run git push origin, it will check the URL of
origin to contain "git.apache.org/flink.git". If the remote branch is
master, it will run the 'mvn clean package' and then fail to push if
maven doesn't exit successfully.

Here some examples where I set protected_remote to my remote at
"ssh://[hidden email]/mxm/flink.git" and protected_branch to "master":


$ git push origin
Verifying push to master via 'maven clean package'.
...
Commits could not be verified. Executed 'mvn clean package' and it returned 1
error: failed to push some refs to 'ssh://[hidden email]/mxm/flink.git'


$ git push origin
Verifying push to master via 'maven clean package'.
...
Counting objects: 12, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (12/12), 838 bytes | 0 bytes/s, done.
Total 12 (delta 5), reused 0 (delta 0)
To ssh://[hidden email]/mxm/flink.git
   ce8acc4..d60197b  master -> master


$ git checkout master
$ git push origin other:master
Please switch to branch "other" to verify.


$ vim README # make some changes
$ git push origin
Please commit or stash your pending changes.


Hope this comes in handy for you.

Best regards,
Max

On Wed, Jan 21, 2015 at 1:46 PM, Max Michels <[hidden email]> wrote:

> @Robert The pre-push hook only resides in your local repository. It
> cannot be pushed. Thus, we cannot enforce this check but it certainly
> helps to prevent mistakes. As Ufuk mentioned, you can then even skip
> the check with the --no-verify option if you're really sure.
>
> On Wed, Jan 21, 2015 at 11:45 AM, Ufuk Celebi <[hidden email]> wrote:
>>
>> On 21 Jan 2015, at 11:40, Robert Metzger <[hidden email]> wrote:
>>
>>> Is the git hook something we can control for everybody? I thought its more
>>> like a personal thing everybody can set up if wanted?
>>>
>>> I'm against enforcing something like this for every committer. I don't want
>>> to wait for 15 minutes for pushing a typo fix to the documentation.
>>
>> Sorry, I didn't mean to have it in the repo. As long as we notice failing builds fast enough (aka email notification), it should be OK to keep it that way. As you said, every committer should decide this on her own. BTW You can always skip hooks with git push -n (--no-verify).

[Ufuk Celebi-2]

Thanks for the nice script. I've just installed it :-)

On 21 Jan 2015, at 13:57, Max Michels <[hidden email]> wrote:

> I've created a pre-push hook that does what I described (and a bit
> more). It does only enforce a check for the remote flink master branch
> and doesn't disturb you on your pushes.
>
> https://gist.github.com/mxm/4d1e26b901c66a682e4a
>
> Just put the the file in the .git/hooks/ directory of your repository directory.
>
> For example, if you run git push origin, it will check the URL of
> origin to contain "git.apache.org/flink.git". If the remote branch is
> master, it will run the 'mvn clean package' and then fail to push if
> maven doesn't exit successfully.
>
> Here some examples where I set protected_remote to my remote at
> "ssh://[hidden email]/mxm/flink.git" and protected_branch to "master":
>
>
> $ git push origin
> Verifying push to master via 'maven clean package'.
> ...
> Commits could not be verified. Executed 'mvn clean package' and it returned 1
> error: failed to push some refs to 'ssh://[hidden email]/mxm/flink.git'
>
>
> $ git push origin
> Verifying push to master via 'maven clean package'.
> ...
> Counting objects: 12, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (8/8), done.
> Writing objects: 100% (12/12), 838 bytes | 0 bytes/s, done.
> Total 12 (delta 5), reused 0 (delta 0)
> To ssh://[hidden email]/mxm/flink.git
>   ce8acc4..d60197b  master -> master
>
>
> $ git checkout master
> $ git push origin other:master
> Please switch to branch "other" to verify.
>
>
> $ vim README # make some changes
> $ git push origin
> Please commit or stash your pending changes.
>
>
> Hope this comes in handy for you.
>
> Best regards,
> Max
>
> On Wed, Jan 21, 2015 at 1:46 PM, Max Michels <[hidden email]> wrote:
>> @Robert The pre-push hook only resides in your local repository. It
>> cannot be pushed. Thus, we cannot enforce this check but it certainly
>> helps to prevent mistakes. As Ufuk mentioned, you can then even skip
>> the check with the --no-verify option if you're really sure.
>>
>> On Wed, Jan 21, 2015 at 11:45 AM, Ufuk Celebi <[hidden email]> wrote:
>>>
>>> On 21 Jan 2015, at 11:40, Robert Metzger <[hidden email]> wrote:
>>>
>>>> Is the git hook something we can control for everybody? I thought its more
>>>> like a personal thing everybody can set up if wanted?
>>>>
>>>> I'm against enforcing something like this for every committer. I don't want
>>>> to wait for 15 minutes for pushing a typo fix to the documentation.
>>>
>>> Sorry, I didn't mean to have it in the repo. As long as we notice failing builds fast enough (aka email notification), it should be OK to keep it that way. As you said, every committer should decide this on her own. BTW You can always skip hooks with git push -n (--no-verify).

[Henry Saputra]

Would it be better to use Github Jenkins plugin [1] to connect to ASF
Jenkins cluster?

[1] https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin
[2] http://events.linuxfoundation.org/sites/events/files/slides/Jenkins_at_ASF_2014.pdf

On Tue, Jan 20, 2015 at 2:57 PM, Robert Metzger <[hidden email]> wrote:

> Hi,
>
> it seems that our master is currently not building. See:
> https://travis-ci.org/apache/flink/jobs/47689754
>
> We need to come up with a good solution to notify dev@flink when builds on
> Travis are failing.
>
> We also had unstable builds recently due to too short akka timeouts and it
> took some time to realize that.
>
> Usually, travis has a pretty good email notification system, but thats not
> working for us because the repository is owned by the "apache" github user.
> I think only users with admin permissions at "apache/flink" are notified by
> email from travis.
>
> There are certainly ways to fix this. Right now, the best approach is
> probably setting up a REST 2 e-mail service somewhere which is mailing to
> our dev@ list (
> http://docs.travis-ci.com/user/notifications/#Webhook-notification).
>
>
> Robert

[Robert Metzger]

I'm actually quite happy with the travis setup. Since most of the
contributors/committers have travis activated for their forks, its very
convenient to run tests on travis, without polluting any public apache
infrastructure.
Also, it would add another big dependency to a (perceived) unstable apache
infrastructure.
Lastly, I don't know if anybody has time right now to migrate away.

I think hacking a little REST2Mail service in Java for the Google Cloud is
a nice task for some wellness-programming on the weekend.

On Wed, Jan 21, 2015 at 9:29 PM, Henry Saputra <[hidden email]>
wrote:

> Would it be better to use Github Jenkins plugin [1] to connect to ASF
> Jenkins cluster?
>
> [1]
> https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin
> [2]
> http://events.linuxfoundation.org/sites/events/files/slides/Jenkins_at_ASF_2014.pdf
>
> On Tue, Jan 20, 2015 at 2:57 PM, Robert Metzger <[hidden email]>
> wrote:
> > Hi,
> >
> > it seems that our master is currently not building. See:
> > https://travis-ci.org/apache/flink/jobs/47689754
> >
> > We need to come up with a good solution to notify dev@flink when builds
> on
> > Travis are failing.
> >
> > We also had unstable builds recently due to too short akka timeouts and
> it
> > took some time to realize that.
> >
> > Usually, travis has a pretty good email notification system, but thats
> not
> > working for us because the repository is owned by the "apache" github
> user.
> > I think only users with admin permissions at "apache/flink" are notified
> by
> > email from travis.
> >
> > There are certainly ways to fix this. Right now, the best approach is
> > probably setting up a REST 2 e-mail service somewhere which is mailing to
> > our dev@ list (
> > http://docs.travis-ci.com/user/notifications/#Webhook-notification).
> >
> >
> > Robert
>

[Ufuk Celebi-2]

I just found out that we can simply activate email notifications for build
failures.

Can we allow [hidden email] to send to [hidden email]?

On Wed, Jan 21, 2015 at 9:41 PM, Robert Metzger <[hidden email]> wrote:

> I'm actually quite happy with the travis setup. Since most of the
> contributors/committers have travis activated for their forks, its very
> convenient to run tests on travis, without polluting any public apache
> infrastructure.
> Also, it would add another big dependency to a (perceived) unstable apache
> infrastructure.
> Lastly, I don't know if anybody has time right now to migrate away.
>
> I think hacking a little REST2Mail service in Java for the Google Cloud is
> a nice task for some wellness-programming on the weekend.
>
> On Wed, Jan 21, 2015 at 9:29 PM, Henry Saputra <[hidden email]>
> wrote:
>
> > Would it be better to use Github Jenkins plugin [1] to connect to ASF
> > Jenkins cluster?
> >
> > [1]
> >
> https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin
> > [2]
> >
> http://events.linuxfoundation.org/sites/events/files/slides/Jenkins_at_ASF_2014.pdf
> >
> > On Tue, Jan 20, 2015 at 2:57 PM, Robert Metzger <[hidden email]>
> > wrote:
> > > Hi,
> > >
> > > it seems that our master is currently not building. See:
> > > https://travis-ci.org/apache/flink/jobs/47689754
> > >
> > > We need to come up with a good solution to notify dev@flink when
> builds
> > on
> > > Travis are failing.
> > >
> > > We also had unstable builds recently due to too short akka timeouts and
> > it
> > > took some time to realize that.
> > >
> > > Usually, travis has a pretty good email notification system, but thats
> > not
> > > working for us because the repository is owned by the "apache" github
> > user.
> > > I think only users with admin permissions at "apache/flink" are
> notified
> > by
> > > email from travis.
> > >
> > > There are certainly ways to fix this. Right now, the best approach is
> > > probably setting up a REST 2 e-mail service somewhere which is mailing
> to
> > > our dev@ list (
> > > http://docs.travis-ci.com/user/notifications/#Webhook-notification).
> > >
> > >
> > > Robert
> >
>

[Robert Metzger]

No, I think this won't work because travis only sends emails to accounts
associated with the repository. In this case its the apache/flink github
repository and nobody of us is actually part of the organization.

See http://docs.travis-ci.com/user/notifications/:

> The most common cause for not receiving build notifications, beyond not
> having a user account on Travis CI, is the use of an email address that's
> not registered and verified on GitHub. See above on how to change the email
> address to one that's registered or make sure to add the email address used
> in this repository to your verified email addresses on GitHub.


I don't know if we can verify our dev list with travis/github. And if, I
don't know if the mailinglists support HTML mails.


On Thu, Feb 12, 2015 at 3:03 PM, Ufuk Celebi <[hidden email]> wrote:

> I just found out that we can simply activate email notifications for build
> failures.
>
> Can we allow [hidden email] to send to [hidden email]?
>
> On Wed, Jan 21, 2015 at 9:41 PM, Robert Metzger <[hidden email]>
> wrote:
>
> > I'm actually quite happy with the travis setup. Since most of the
> > contributors/committers have travis activated for their forks, its very
> > convenient to run tests on travis, without polluting any public apache
> > infrastructure.
> > Also, it would add another big dependency to a (perceived) unstable
> apache
> > infrastructure.
> > Lastly, I don't know if anybody has time right now to migrate away.
> >
> > I think hacking a little REST2Mail service in Java for the Google Cloud
> is
> > a nice task for some wellness-programming on the weekend.
> >
> > On Wed, Jan 21, 2015 at 9:29 PM, Henry Saputra <[hidden email]>
> > wrote:
> >
> > > Would it be better to use Github Jenkins plugin [1] to connect to ASF
> > > Jenkins cluster?
> > >
> > > [1]
> > >
> >
> https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin
> > > [2]
> > >
> >
> http://events.linuxfoundation.org/sites/events/files/slides/Jenkins_at_ASF_2014.pdf
> > >
> > > On Tue, Jan 20, 2015 at 2:57 PM, Robert Metzger <[hidden email]>
> > > wrote:
> > > > Hi,
> > > >
> > > > it seems that our master is currently not building. See:
> > > > https://travis-ci.org/apache/flink/jobs/47689754
> > > >
> > > > We need to come up with a good solution to notify dev@flink when
> > builds
> > > on
> > > > Travis are failing.
> > > >
> > > > We also had unstable builds recently due to too short akka timeouts
> and
> > > it
> > > > took some time to realize that.
> > > >
> > > > Usually, travis has a pretty good email notification system, but
> thats
> > > not
> > > > working for us because the repository is owned by the "apache" github
> > > user.
> > > > I think only users with admin permissions at "apache/flink" are
> > notified
> > > by
> > > > email from travis.
> > > >
> > > > There are certainly ways to fix this. Right now, the best approach is
> > > > probably setting up a REST 2 e-mail service somewhere which is
> mailing
> > to
> > > > our dev@ list (
> > > > http://docs.travis-ci.com/user/notifications/#Webhook-notification).
> > > >
> > > >
> > > > Robert
> > >
> >
>

[Robert Metzger]

Searching for "travis build notifications apache" on Google reveals
actually a commit from our repo:
http://mail-archives.apache.org/mod_mbox/flink-commits/201406.mbox/%3C8be204a6869f4380b0de3135373c0452@...%3E

Tajo also tried this: https://issues.apache.org/jira/browse/TAJO-834
But I didn't see a single mail in their issues@ archive.

Also, this presentation confirms the issue:
http://www.slideshare.net/jukka/apache-development-with-github-and-travis-ci

On Thu, Feb 12, 2015 at 3:07 PM, Robert Metzger <[hidden email]> wrote:

> No, I think this won't work because travis only sends emails to accounts
> associated with the repository. In this case its the apache/flink github
> repository and nobody of us is actually part of the organization.
>
> See http://docs.travis-ci.com/user/notifications/:
>
>> The most common cause for not receiving build notifications, beyond not
>> having a user account on Travis CI, is the use of an email address that's
>> not registered and verified on GitHub. See above on how to change the email
>> address to one that's registered or make sure to add the email address used
>> in this repository to your verified email addresses on GitHub.
>
>
> I don't know if we can verify our dev list with travis/github. And if, I
> don't know if the mailinglists support HTML mails.
>
>
> On Thu, Feb 12, 2015 at 3:03 PM, Ufuk Celebi <[hidden email]> wrote:
>
>> I just found out that we can simply activate email notifications for build
>> failures.
>>
>> Can we allow [hidden email] to send to [hidden email]?
>>
>> On Wed, Jan 21, 2015 at 9:41 PM, Robert Metzger <[hidden email]>
>> wrote:
>>
>> > I'm actually quite happy with the travis setup. Since most of the
>> > contributors/committers have travis activated for their forks, its very
>> > convenient to run tests on travis, without polluting any public apache
>> > infrastructure.
>> > Also, it would add another big dependency to a (perceived) unstable
>> apache
>> > infrastructure.
>> > Lastly, I don't know if anybody has time right now to migrate away.
>> >
>> > I think hacking a little REST2Mail service in Java for the Google Cloud
>> is
>> > a nice task for some wellness-programming on the weekend.
>> >
>> > On Wed, Jan 21, 2015 at 9:29 PM, Henry Saputra <[hidden email]
>> >
>> > wrote:
>> >
>> > > Would it be better to use Github Jenkins plugin [1] to connect to ASF
>> > > Jenkins cluster?
>> > >
>> > > [1]
>> > >
>> >
>> https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin
>> > > [2]
>> > >
>> >
>> http://events.linuxfoundation.org/sites/events/files/slides/Jenkins_at_ASF_2014.pdf
>> > >
>> > > On Tue, Jan 20, 2015 at 2:57 PM, Robert Metzger <[hidden email]>
>> > > wrote:
>> > > > Hi,
>> > > >
>> > > > it seems that our master is currently not building. See:
>> > > > https://travis-ci.org/apache/flink/jobs/47689754
>> > > >
>> > > > We need to come up with a good solution to notify dev@flink when
>> > builds
>> > > on
>> > > > Travis are failing.
>> > > >
>> > > > We also had unstable builds recently due to too short akka timeouts
>> and
>> > > it
>> > > > took some time to realize that.
>> > > >
>> > > > Usually, travis has a pretty good email notification system, but
>> thats
>> > > not
>> > > > working for us because the repository is owned by the "apache"
>> github
>> > > user.
>> > > > I think only users with admin permissions at "apache/flink" are
>> > notified
>> > > by
>> > > > email from travis.
>> > > >
>> > > > There are certainly ways to fix this. Right now, the best approach
>> is
>> > > > probably setting up a REST 2 e-mail service somewhere which is
>> mailing
>> > to
>> > > > our dev@ list (
>> > > > http://docs.travis-ci.com/user/notifications/#Webhook-notification
>> ).
>> > > >
>> > > >
>> > > > Robert
>> > >
>> >
>>
>
>