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 |
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 |
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 > |
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 > > > |
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 >> > >> |
@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 > >> > > >> > |
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 > > >> > > > >> > > > |
Free forum by Nabble | Edit this page |