<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 21, 2014 at 11:59 AM, Sebastian Łaskawiec <span dir="ltr"><<a href="mailto:slaskawi@redhat.com" target="_blank">slaskawi@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I think we can work on this one...<br>
<br>
First of all - contributors need to know about this rule, perhaps<br>
updating [1] might be a good idea. Official announcement on mailing list<br>
might be also helpful (this email thread is already pretty long, so it<br>
might be missed by many folks).<br></blockquote><div><br></div><div>Like Sanne said, we did decide to go for a green test suite a great many times on this list, so I don't think lack of awareness is an issue. </div><div><br></div><div>In fact, I was volunteered to monitor the TeamCity test results and create a blocker issue for each failing test some time ago, but finding the proper owner for bugs proved to be quite time consuming so I haven't been sticking to it. This thread did motivate me to create a few new blocker issues, however :)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Secondly - we need to stop integrating Pull Requests with new failures.<br>
It's a bit harder when we have some existing failures, because there is<br>
always an excuse (this failure is not related, it's just an unstable<br>
test etc). But once we have clean build - it's a "binary" decision.<br>
I think we might also add some descriptive comment to Pull Request when<br>
the build is unstable - something like "This Pull Request won't be<br>
integrated, because it's unstable. Fix it first.".<br></blockquote><div><br></div><div>Of course, the question is how we are going to achieve that magical clean build status...</div><div><br></div><div><div>At one point we moved the random failing tests to the unstable group/category to remove them from the main build, but I've noticed that we've never really brought back an unstable test, at least in the core, so I've stopped doing it. I figured having the test failures in every email from TeamCity would motivate people to look into those failures, but I'm not sure anyone reads the build failure emails from TeamCity :)</div></div><div><br></div><div>And it's not enough to have one master build with 0 failures. We had that before, and it didn't really help. We have to have at least a week with 0 failures on master (with JDK7, with JDK8, and with TRACE enabled, on the slow EC2 agent, on the fast OpenStack agents etc.) before we can say the build is really clean.</div><div><br></div><div>I'm not saying we can't do it, but I share Sanne's pessimism: this time is not that different from the last time we committed to a clean build.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
[1] <a href="http://infinispan.org/docs/7.0.x/contributing/contributing.html" target="_blank">http://infinispan.org/docs/7.0.x/contributing/contributing.html</a><br>
<span class="im"><br>
On 10/21/2014 10:27 AM, Sanne Grinovero wrote:<br>
> I totally agree here, but it never worked: people regularly ignore<br>
> failing tests, for various reasons.<br>
> We've had similar good intentions expressed many times, but I simply<br>
> have no reason to believe that this time it's going to work out.<br>
<br>
</span><div class=""><div class="h5">_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div></div>