<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 21, 2014 at 2:46 PM, Sanne Grinovero <span dir="ltr"><<a href="mailto:sanne@infinispan.org" target="_blank">sanne@infinispan.org</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">Hi Sebastian,<br>
I'm not against the idea at all, I would really love it and I agree<br>
that this is the biggest pain and waste of time in trying to make<br>
progress on Infinispan. I'm just trying to be realistic and warn you<br>
that these great intentions didn't work in the past.<br>
Now my hope is that maybe we now have more people agreeing on how<br>
important this is, so maybe we're in a better position, and I'm always<br>
willing to try this again.<br>
<br>
I'm sceptical though on embarking into a PR process which assumes that<br>
we're going to be able to keep the testsuite green just because we<br>
decide so; let's first work on a green testsuite, and then proof that<br>
we can keep it that way for a resonsable time.. then we can talk about<br>
building something on reliable foundations.<br></blockquote><div><br></div><div>+1</div><div> </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>
[BTW I can't answer inline as you're sending HTML formatted email and<br>
gmail isn't properly separating your quote from Dan's previous words]<br>
<br>
Why would you delete the tests and not simply ignore them? You can<br>
revert the change as well.<br>
Both strategies would have the same effect, but ignoring them you<br>
don't need to take notes of what disappeared; best part, is that code<br>
using APIs get refactored together with other changes, and you<br>
minimize conflicts as you minimize the number of lines being changed.<br></blockquote><div><br></div><div>Hey, if fixing compilation errors would have been enough, we wouldn't have so many tests in the unstable group that *always* fail.</div><div><br></div><div>So Sebastian has a point, if we don't have a clear deadline for bringing the failing tests back into the main build, we might as well delete them. Except I don't want to delete tests, I want to make them work. And I didn't see anything in his proposal about tests that fail only once a week, or only on a certain agent, or only if TRACE logging is enabled...</div><div><br></div><div>Cheers</div><div>Dan</div><div><br></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">
<span class=""><font color="#888888"><br>
Sanne<br>
</font></span><div class=""><div class="h5"><br>
On 21 October 2014 12:35, Sebastian Łaskawiec <<a href="mailto:slaskawi@redhat.com">slaskawi@redhat.com</a>> wrote:<br>
> On 10/21/2014 12:47 PM, Dan Berindei wrote:<br>
><br>
> In fact, I was volunteered to monitor the TeamCity test results and create a<br>
> blocker issue for each failing test some time ago, but finding the proper<br>
> owner for bugs proved to be quite time consuming so I haven't been sticking<br>
> to it. This thread did motivate me to create a few new blocker issues,<br>
> however :)<br>
><br>
> I believe we need to change our strategy in this point. We don't want to<br>
> create new issues - we want to motivate everybody to fix it (and fix it<br>
> fast). As I said - when the failure gets into our repo - all successive Pull<br>
> Requests will start to fail. Nobody will be able to integrate his changes<br>
> and everybody (not everybody - some guys which are in hurry) will probably<br>
> want to unblock themselves... The easiest way to do that is to fix the<br>
> build...</div></div></blockquote><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"><div class=""><div class="h5">
><br>
> This is the main idea... To make failing test a serious problem and not just<br>
> another "easy to ignore" issue...</div></div></blockquote><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"><div class=""><div class="h5">
><br>
> Of course, the question is how we are going to achieve that magical clean<br>
> build status...<br>
><br>
> I've got some idea - it's pretty controversial, but maybe you will like it<br>
> :)<br>
><br>
> Remove every failing test from our code base - just delete it (no ignoring,<br>
> no adding to separate testsuite - just delete).<br>
> Create separate branch and place all those tests there - simply revert<br>
> commit which removed them from master.<br>
> Organize failed-test-bounty with our Community - ask them to fix as many as<br>
> possible during fixed amount of time (a month or two? maybe shorter?).<br>
> Every contributor in failed-test-bounty will be listed in "Thanks" section<br>
> of the release notes<br>
> After the bounty is over, we'll just delete tests which were not fixed...<br></div></div></blockquote><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"><div class=""><div class="h5">><br>
><br>
><br>
</div></div><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>
<br>
_______________________________________________<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></div></div></blockquote></div><br></div></div>