+1, good point. My bad, I think I was the one who accepted this patch …. On 9 Sep 2011, at 14:32, Sanne Grinovero wrote: > Hi all, > I know nobody cares about Query.. but some of the commits of > today/yesterday broke it. > > I think both the pull-requestor and the reviewer should run a full > build before allowing any change to be pushed upstream; with a script > like this one: > https://gist.github.com/789588 > > it won't even prevent you to work on a different branch while tests > test are run, so while it takes some CPU, you can still look at other > stuff. > > Sanne > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 13 September 2011 11:21, Galder Zamarreño <galder(a)redhat.com&gt; wrote: > Not sure what machine you have but tbh, if I run the tests on my MBP, I can hardly do other stuff, particularly development. I'd need a separate machine for that. I have a dual core, likely it's not the hardware making the difference :P It slows down the system a bit, fans spin up, but other applications stay responsive enough. > It's true that I should at least run the build to make sure the rest compiles but this stuff should be caught by CI too? Granted that it would not have picked it cos of https://issues.jboss.org/browse/ISPN-1381 > > Guys, we have CI for something. If something's wrong, it needs to be flagged, not wait for 1 month (that includes me of course). Right but the CI is worthless. Since the tests fail so often that nobody reads the alarms it sends. I'm still of the idea that master should always pass all tests - we've been very close with just a couple of tests failing but I can't remember having it ever seen all green/blue - not complaining and it's my responsibility as well, just that we can't rely on CI for this until we take the time to seriously review the testsuite.

Sanne > > On Sep 12, 2011, at 4:09 PM, Manik Surtani wrote: > >> +1, good point. My bad, I think I was the one who accepted this patch …. >> >> On 9 Sep 2011, at 14:32, Sanne Grinovero wrote: >> >>> Hi all, >>> I know nobody cares about Query.. but some of the commits of >>> today/yesterday broke it. >>> >>> I think both the pull-requestor and the reviewer should run a full >>> build before allowing any change to be pushed upstream; with a script >>> like this one: >>> https://gist.github.com/789588 >>> >>> it won't even prevent you to work on a different branch while tests >>> test are run, so while it takes some CPU, you can still look at other >>> stuff. >>> >>> Sanne >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Manik Surtani >> manik(a)jboss.org >> twitter.com/maniksurtani >> >> Lead, Infinispan >> http://www.infinispan.org >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 13 September 2011 12:57, Galder Zamarreño <galder(a)redhat.com&gt; wrote: > > On Sep 13, 2011, at 12:14 PM, Sanne Grinovero wrote: > >> On 13 September 2011 11:21, Galder Zamarreño <galder(a)redhat.com&gt; wrote: >>> Not sure what machine you have but tbh, if I run the tests on my MBP, I can hardly do other stuff, particularly development. I'd need a separate machine for that. >> >> I have a dual core, likely it's not the hardware making the difference >> :P It slows down the system a bit, fans spin up, but other >> applications stay responsive enough. >> >>> It's true that I should at least run the build to make sure the rest compiles but this stuff should be caught by CI too? Granted that it would not have picked it cos of https://issues.jboss.org/browse/ISPN-1381 >>> >>> Guys, we have CI for something. If something's wrong, it needs to be flagged, not wait for 1 month (that includes me of course). >> >> Right but the CI is worthless. >> Since the tests fail so often that nobody reads the alarms it sends. >> I'm still of the idea that master should always pass all tests - we've >> been very close with just a couple of tests failing but I can't >> remember having it ever seen all green/blue - not complaining and it's >> my responsibility as well, just that we can't rely on CI for this >> until we take the time to seriously review the testsuite. > > I disagree :) - The CI is definitely worth it. Sure, some tests might need revisiting but a big majority of the tests are working fine: > https://infinispan.ci.cloudbees.com/job/Infinispan-master-JDK6-tcp/218/ > > We're down to about 13 failures in a testsuite of probably 2000 tests or so. That is very good already. > > I don't think the testsuite is in such state that requires someone to spend a few days trying to get it work perfectly. It's desirable but we've got bigger issues to deal with IMO. > > I'm more of a thinker that if you're working on something and you happen to encounter and test that fails randomly, fix it. You'll already have the knowledge of that code as a result of your work and will prob make it easier to fix the test or the underlying bug. IOW, I'm trying to be pragmatic here. right and I agree with you that this is the best we can do right now. But when the build broke, nobody noticed until the day after, and even then it happened because by chance I needed a fresh build of Query. I'm just guessing that since Jenkins is always complaining we don't give enough attentions to his emails, making the CI less effective than what it could be: on other projects a CI failure notification makes me run to the computer to make sure it's immediately fixed, not so with Infinispan as it's no news. Sanne _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

I think both the pull-requestor and the reviewer should run a full build before allowing any change to be pushed upstream; with a script like this one: https://gist.github.com/789588 it won't even prevent you to work on a different branch while tests test are run, so while it takes some CPU, you can still look at other stuff.