@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 <u...@apache.org> 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 <se...@apache.org> 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 <bowen...@offerupnow.com>
> 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 <u...@apache.org> 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 <c...@greghogan.com>
> 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
> >> >
> >>
>
