[DISCUSS] TravisCI status on GitHub Page

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] TravisCI status on GitHub Page

Greg Hogan
We are now showing the TravisCI build status on Flink’s GitHub page. I think Robert’s comment in Jira may have gone unnoticed when the PR was committed.
  https://issues.apache.org/jira/browse/FLINK-6122 <https://issues.apache.org/jira/browse/FLINK-6122>

If not yet seeing the benefit even if builds were typically passing.

Greg
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] TravisCI status on GitHub Page

Ufuk Celebi-2
I merged the PR and therefore obviously think it's fine. ;-) Didn't
see Robert's comment in the issue though ("We once had the travis
build status badge in our readme, but decided to remove it, because it
often shows "Build failed" due to travis issues etc.
This gives people the impression that our builds are very unstable").

It's actually not just an impression, but actually true that the
builds are unstable (even if recently it's "mostly" caused by
timeouts). Since we are actively working on improving this situation
with the repository split, I think it does not hurt having it there.
If others disagree, we can revert it.


On Mon, Mar 20, 2017 at 2:12 PM, Greg Hogan <[hidden email]> wrote:
> We are now showing the TravisCI build status on Flink’s GitHub page. I think Robert’s comment in Jira may have gone unnoticed when the PR was committed.
>   https://issues.apache.org/jira/browse/FLINK-6122 <https://issues.apache.org/jira/browse/FLINK-6122>
>
> If not yet seeing the benefit even if builds were typically passing.
>
> Greg
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] TravisCI status on GitHub Page

Bowen Li
I would argue for benefits of having build status.

Instead of letting people go through all docs and wikis to find how Flink
build system works, it guides people directly to where builds actually
happen and ramps up new contributors faster. When my local tests fail
during development, the homepage is the single place I would like to visit
and find out if my local errors are from master branch.

It also reminds everyone in the community that what the state of our
project is - failing? check out errors directly and fix them, also remind
yourself be cautious when developing code; passing? that's great, and
everyone in this project has been doing an excellent job!

I don't like to pretend the project is healthy and stable all the time
because it is not and will never be. Removing a way that problems surface
is not a way to make it better. I feel it actually gives people a positive
impression that Flink is an up-to-date project, because older projects
don't usually have it according to my observation.

On Mon, Mar 20, 2017 at 6:20 AM, Ufuk Celebi <[hidden email]> wrote:

> I merged the PR and therefore obviously think it's fine. ;-) Didn't
> see Robert's comment in the issue though ("We once had the travis
> build status badge in our readme, but decided to remove it, because it
> often shows "Build failed" due to travis issues etc.
> This gives people the impression that our builds are very unstable").
>
> It's actually not just an impression, but actually true that the
> builds are unstable (even if recently it's "mostly" caused by
> timeouts). Since we are actively working on improving this situation
> with the repository split, I think it does not hurt having it there.
> If others disagree, we can revert it.
>
>
> On Mon, Mar 20, 2017 at 2:12 PM, Greg Hogan <[hidden email]> wrote:
> > We are now showing the TravisCI build status on Flink’s GitHub page. I
> think Robert’s comment in Jira may have gone unnoticed when the PR was
> committed.
> >   https://issues.apache.org/jira/browse/FLINK-6122 <
> https://issues.apache.org/jira/browse/FLINK-6122>
> >
> > If not yet seeing the benefit even if builds were typically passing.
> >
> > Greg
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] TravisCI status on GitHub Page

Stephan Ewen
Copying my answer from JIRA:

Many builds are marked as "failed" these days simply due to exceeding the
50 minute limit in one profile.
The status kind of makes the project look bad without a reason.

We have quasi never a broken master, and currently not even flaky tests :-)
For a code base of that size, that's a remarkable job by the community.
Would be a pity if this is reflected differently to the works for reasons
of timeouts and build infrastructure issues.

I am +1 for removing the tag.



On Tue, Mar 21, 2017 at 5:51 AM, Bowen Li <[hidden email]> wrote:

> I would argue for benefits of having build status.
>
> Instead of letting people go through all docs and wikis to find how Flink
> build system works, it guides people directly to where builds actually
> happen and ramps up new contributors faster. When my local tests fail
> during development, the homepage is the single place I would like to visit
> and find out if my local errors are from master branch.
>
> It also reminds everyone in the community that what the state of our
> project is - failing? check out errors directly and fix them, also remind
> yourself be cautious when developing code; passing? that's great, and
> everyone in this project has been doing an excellent job!
>
> I don't like to pretend the project is healthy and stable all the time
> because it is not and will never be. Removing a way that problems surface
> is not a way to make it better. I feel it actually gives people a positive
> impression that Flink is an up-to-date project, because older projects
> don't usually have it according to my observation.
>
> On Mon, Mar 20, 2017 at 6:20 AM, Ufuk Celebi <[hidden email]> wrote:
>
> > I merged the PR and therefore obviously think it's fine. ;-) Didn't
> > see Robert's comment in the issue though ("We once had the travis
> > build status badge in our readme, but decided to remove it, because it
> > often shows "Build failed" due to travis issues etc.
> > This gives people the impression that our builds are very unstable").
> >
> > It's actually not just an impression, but actually true that the
> > builds are unstable (even if recently it's "mostly" caused by
> > timeouts). Since we are actively working on improving this situation
> > with the repository split, I think it does not hurt having it there.
> > If others disagree, we can revert it.
> >
> >
> > On Mon, Mar 20, 2017 at 2:12 PM, Greg Hogan <[hidden email]> wrote:
> > > We are now showing the TravisCI build status on Flink’s GitHub page. I
> > think Robert’s comment in Jira may have gone unnoticed when the PR was
> > committed.
> > >   https://issues.apache.org/jira/browse/FLINK-6122 <
> > https://issues.apache.org/jira/browse/FLINK-6122>
> > >
> > > If not yet seeing the benefit even if builds were typically passing.
> > >
> > > Greg
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] TravisCI status on GitHub Page

Ufuk Celebi-2
The tag says "errored" in case of the timeout.

But I don't think it's a worthwhile discussion to have, so I just
reverted the commit.


On Tue, Mar 21, 2017 at 2:50 PM, Stephan Ewen <[hidden email]> wrote:

> Copying my answer from JIRA:
>
> Many builds are marked as "failed" these days simply due to exceeding the
> 50 minute limit in one profile.
> The status kind of makes the project look bad without a reason.
>
> We have quasi never a broken master, and currently not even flaky tests :-)
> For a code base of that size, that's a remarkable job by the community.
> Would be a pity if this is reflected differently to the works for reasons
> of timeouts and build infrastructure issues.
>
> I am +1 for removing the tag.
>
>
>
> On Tue, Mar 21, 2017 at 5:51 AM, Bowen Li <[hidden email]> wrote:
>
>> I would argue for benefits of having build status.
>>
>> Instead of letting people go through all docs and wikis to find how Flink
>> build system works, it guides people directly to where builds actually
>> happen and ramps up new contributors faster. When my local tests fail
>> during development, the homepage is the single place I would like to visit
>> and find out if my local errors are from master branch.
>>
>> It also reminds everyone in the community that what the state of our
>> project is - failing? check out errors directly and fix them, also remind
>> yourself be cautious when developing code; passing? that's great, and
>> everyone in this project has been doing an excellent job!
>>
>> I don't like to pretend the project is healthy and stable all the time
>> because it is not and will never be. Removing a way that problems surface
>> is not a way to make it better. I feel it actually gives people a positive
>> impression that Flink is an up-to-date project, because older projects
>> don't usually have it according to my observation.
>>
>> On Mon, Mar 20, 2017 at 6:20 AM, Ufuk Celebi <[hidden email]> wrote:
>>
>> > I merged the PR and therefore obviously think it's fine. ;-) Didn't
>> > see Robert's comment in the issue though ("We once had the travis
>> > build status badge in our readme, but decided to remove it, because it
>> > often shows "Build failed" due to travis issues etc.
>> > This gives people the impression that our builds are very unstable").
>> >
>> > It's actually not just an impression, but actually true that the
>> > builds are unstable (even if recently it's "mostly" caused by
>> > timeouts). Since we are actively working on improving this situation
>> > with the repository split, I think it does not hurt having it there.
>> > If others disagree, we can revert it.
>> >
>> >
>> > On Mon, Mar 20, 2017 at 2:12 PM, Greg Hogan <[hidden email]> wrote:
>> > > We are now showing the TravisCI build status on Flink’s GitHub page. I
>> > think Robert’s comment in Jira may have gone unnoticed when the PR was
>> > committed.
>> > >   https://issues.apache.org/jira/browse/FLINK-6122 <
>> > https://issues.apache.org/jira/browse/FLINK-6122>
>> > >
>> > > If not yet seeing the benefit even if builds were typically passing.
>> > >
>> > > Greg
>> >
>>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] TravisCI status on GitHub Page

Stephan Ewen
@Bowen Li

There are various discussions currently about reworking repository
structure, tests, even switching CI services.
I would be up for revisiting this questions once we care confident that the
CI infrastructure does not mark "good state" as "broken".


On Tue, Mar 21, 2017 at 3:02 PM, Ufuk Celebi <[hidden email]> wrote:

> The tag says "errored" in case of the timeout.
>
> But I don't think it's a worthwhile discussion to have, so I just
> reverted the commit.
>
>
> On Tue, Mar 21, 2017 at 2:50 PM, Stephan Ewen <[hidden email]> wrote:
> > Copying my answer from JIRA:
> >
> > Many builds are marked as "failed" these days simply due to exceeding the
> > 50 minute limit in one profile.
> > The status kind of makes the project look bad without a reason.
> >
> > We have quasi never a broken master, and currently not even flaky tests
> :-)
> > For a code base of that size, that's a remarkable job by the community.
> > Would be a pity if this is reflected differently to the works for reasons
> > of timeouts and build infrastructure issues.
> >
> > I am +1 for removing the tag.
> >
> >
> >
> > On Tue, Mar 21, 2017 at 5:51 AM, Bowen Li <[hidden email]>
> wrote:
> >
> >> I would argue for benefits of having build status.
> >>
> >> Instead of letting people go through all docs and wikis to find how
> Flink
> >> build system works, it guides people directly to where builds actually
> >> happen and ramps up new contributors faster. When my local tests fail
> >> during development, the homepage is the single place I would like to
> visit
> >> and find out if my local errors are from master branch.
> >>
> >> It also reminds everyone in the community that what the state of our
> >> project is - failing? check out errors directly and fix them, also
> remind
> >> yourself be cautious when developing code; passing? that's great, and
> >> everyone in this project has been doing an excellent job!
> >>
> >> I don't like to pretend the project is healthy and stable all the time
> >> because it is not and will never be. Removing a way that problems
> surface
> >> is not a way to make it better. I feel it actually gives people a
> positive
> >> impression that Flink is an up-to-date project, because older projects
> >> don't usually have it according to my observation.
> >>
> >> On Mon, Mar 20, 2017 at 6:20 AM, Ufuk Celebi <[hidden email]> wrote:
> >>
> >> > I merged the PR and therefore obviously think it's fine. ;-) Didn't
> >> > see Robert's comment in the issue though ("We once had the travis
> >> > build status badge in our readme, but decided to remove it, because it
> >> > often shows "Build failed" due to travis issues etc.
> >> > This gives people the impression that our builds are very unstable").
> >> >
> >> > It's actually not just an impression, but actually true that the
> >> > builds are unstable (even if recently it's "mostly" caused by
> >> > timeouts). Since we are actively working on improving this situation
> >> > with the repository split, I think it does not hurt having it there.
> >> > If others disagree, we can revert it.
> >> >
> >> >
> >> > On Mon, Mar 20, 2017 at 2:12 PM, Greg Hogan <[hidden email]>
> wrote:
> >> > > We are now showing the TravisCI build status on Flink’s GitHub
> page. I
> >> > think Robert’s comment in Jira may have gone unnoticed when the PR was
> >> > committed.
> >> > >   https://issues.apache.org/jira/browse/FLINK-6122 <
> >> > https://issues.apache.org/jira/browse/FLINK-6122>
> >> > >
> >> > > If not yet seeing the benefit even if builds were typically passing.
> >> > >
> >> > > Greg
> >> >
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] TravisCI status on GitHub Page

Bowen Li
ok, fair enough

On Tue, Mar 21, 2017 at 11:00 AM, Stephan Ewen <[hidden email]> wrote:

> @Bowen Li
>
> There are various discussions currently about reworking repository
> structure, tests, even switching CI services.
> I would be up for revisiting this questions once we care confident that the
> CI infrastructure does not mark "good state" as "broken".
>
>
> On Tue, Mar 21, 2017 at 3:02 PM, Ufuk Celebi <[hidden email]> wrote:
>
> > The tag says "errored" in case of the timeout.
> >
> > But I don't think it's a worthwhile discussion to have, so I just
> > reverted the commit.
> >
> >
> > On Tue, Mar 21, 2017 at 2:50 PM, Stephan Ewen <[hidden email]> wrote:
> > > Copying my answer from JIRA:
> > >
> > > Many builds are marked as "failed" these days simply due to exceeding
> the
> > > 50 minute limit in one profile.
> > > The status kind of makes the project look bad without a reason.
> > >
> > > We have quasi never a broken master, and currently not even flaky tests
> > :-)
> > > For a code base of that size, that's a remarkable job by the community.
> > > Would be a pity if this is reflected differently to the works for
> reasons
> > > of timeouts and build infrastructure issues.
> > >
> > > I am +1 for removing the tag.
> > >
> > >
> > >
> > > On Tue, Mar 21, 2017 at 5:51 AM, Bowen Li <[hidden email]>
> > wrote:
> > >
> > >> I would argue for benefits of having build status.
> > >>
> > >> Instead of letting people go through all docs and wikis to find how
> > Flink
> > >> build system works, it guides people directly to where builds actually
> > >> happen and ramps up new contributors faster. When my local tests fail
> > >> during development, the homepage is the single place I would like to
> > visit
> > >> and find out if my local errors are from master branch.
> > >>
> > >> It also reminds everyone in the community that what the state of our
> > >> project is - failing? check out errors directly and fix them, also
> > remind
> > >> yourself be cautious when developing code; passing? that's great, and
> > >> everyone in this project has been doing an excellent job!
> > >>
> > >> I don't like to pretend the project is healthy and stable all the time
> > >> because it is not and will never be. Removing a way that problems
> > surface
> > >> is not a way to make it better. I feel it actually gives people a
> > positive
> > >> impression that Flink is an up-to-date project, because older projects
> > >> don't usually have it according to my observation.
> > >>
> > >> On Mon, Mar 20, 2017 at 6:20 AM, Ufuk Celebi <[hidden email]> wrote:
> > >>
> > >> > I merged the PR and therefore obviously think it's fine. ;-) Didn't
> > >> > see Robert's comment in the issue though ("We once had the travis
> > >> > build status badge in our readme, but decided to remove it, because
> it
> > >> > often shows "Build failed" due to travis issues etc.
> > >> > This gives people the impression that our builds are very
> unstable").
> > >> >
> > >> > It's actually not just an impression, but actually true that the
> > >> > builds are unstable (even if recently it's "mostly" caused by
> > >> > timeouts). Since we are actively working on improving this situation
> > >> > with the repository split, I think it does not hurt having it there.
> > >> > If others disagree, we can revert it.
> > >> >
> > >> >
> > >> > On Mon, Mar 20, 2017 at 2:12 PM, Greg Hogan <[hidden email]>
> > wrote:
> > >> > > We are now showing the TravisCI build status on Flink’s GitHub
> > page. I
> > >> > think Robert’s comment in Jira may have gone unnoticed when the PR
> was
> > >> > committed.
> > >> > >   https://issues.apache.org/jira/browse/FLINK-6122 <
> > >> > https://issues.apache.org/jira/browse/FLINK-6122>
> > >> > >
> > >> > > If not yet seeing the benefit even if builds were typically
> passing.
> > >> > >
> > >> > > Greg
> > >> >
> > >>
> >
>