[infinispan-dev] Let's stop with pull requests

[Galder Zamarreño]

On May 30, 2012, at 2:28 PM, Sanne Grinovero wrote:

> On 30 May 2012 13:24, Manik Surtani <manik at jboss.org> wrote:
>> 
>> On 30 May 2012, at 13:00, Dan Berindei wrote:
>> 
>>> On Tue, May 29, 2012 at 1:48 PM, Manik Surtani <manik at jboss.org> wrote:
>>>> I pretty much agree with this; and here's a bit of history.
>>>> 
>>>> For the large part we have had a stable test suite, but the occasional unpredictability in the suite came in when we introduced the parallel test runner, to allow us to run the (core) suite in under 5 minutes - a suite which otherwise took over 2 hours when run sequentially.
>>>> 
>>>> We could revert back to just using the sequential test runner if people prefer that - it makes the suite run more predictably and hence easier to debug and maintain - but the drawback is, well, it takes 2 hours to run.
>>>> 
>>>> Perhaps we should use the parallel suite as a "smoke test", but in the event of any failures, revert to a run using the sequential suite?
>>>> 
>>> 
>>> -1, a smoke test should be something that is not only faster but
>>> always passes, so we could run that on each pull req. Getting a FAIL
>>> from buildhive on each pull request would get tiring real quick.
>> 
>> Agreed.  I know I have asked for this before, could we please try one more time, to identify *all* tests that are known to periodically fail?  I know the parallel suite doesn't affect *all* tests in the same way.
> 
> +1000 let's open an issue for each test that fails, even if it fails
> occasionally. If it can't be fixed, the test is doing more harm than
> any good and should be either redesigned or removed.

^ I think we all agree on this and that's what I'm planning to do for each random test failure I see or spot.

Preferably, I'm gonna limit these to those situations where I have TRACE logging, otherwise it can often be pretty hard seeing the root cause.

> 
> Let's hope the Spring and CDI failures can be grouped however.. sorry
> I'll resume my hacks on the Spring module today, but hope someone else
> can take care of CDI and the others. Ideally we should appoint
> individuals responsible for each module, so to divide this task.

CDI stuff is pretty odd, as I was saying to Manik yesterday:

"Looks fine (CDI module testsuite) here in master. 5.1.x cmd line testsuite throws:

Failed tests:   testDefaultCache(org.infinispan.cdi.test.cache.remote.DefaultCacheTest): java.lang.IllegalStateException: Unable to instantiate Netty's unsafe dynamic channel buffer
 testNamedCache(org.infinispan.cdi.test.cache.remote.NamedCacheTest): java.lang.IllegalStateException: Unable to instantiate Netty's unsafe dynamic channel buffer
 testSpecificCacheManager(org.infinispan.cdi.test.cache.remote.SpecificCacheManagerTest): java.lang.IllegalStateException: Unable to instantiate Netty's unsafe dynamic channel buffer

Which I cannot replicate via IDE, and in the IDE, DefaultCacheTest throws something completely different: https://gist.github.com/2837235

Both of which, do not look anything like the NPE in: http://goo.gl/a2TDr

Gotta love unit testing, eh? ;)"

> 
> Cheers,
> Sanne
> 
> 
> 
>> 
>> --
>> Manik Surtani
>> manik at jboss.org
>> twitter.com/maniksurtani
>> 
>> Lead, Infinispan
>> http://www.infinispan.org
>> 
>> 
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache