On Sat, Feb 18, 2012 at 11:41 AM, Dawid Weiss <[email protected]> wrote: >> Personally I say 'go for it'. My only concern is that test failures >> reproduce, but this is likely just paranoia from the existing >> code...I'm guessing you have this under control. > > You mean past test failures (with known seeds)?
no that would be crazy!!!! I mean "reproducibility bugs" where somehow a test doesn't reproduce because of bugs in LuceneTestCase :) > > Sure we can add it, you don't even need a macro -- a simple condition > will do. My thinking was that if we're making major changes to the > testing factor we may as well consolidate and simplify to as few > options as possible. There are other non-backward compatible changes > like -Dtestpackageroot is not really covered by globbing filters; you > can simulate it via: Right, I think that we can consolidate more obscure stuff (like testpackageroot), but I was just mentioning i hand-type in -Dtestcase and also -Dtestmethod quite often when debugging and writing tests. > > There is one showstopper issue I'm still trying to track (slave > failing with JSON serialization weirdness). Don't know if it's a > dependency bug (gson) or something else. Once I have that solved, I'll > warn again and commit this to trunk. If there's anything weird going > on with tests on Jenkins we will either revert or fix as we go. Well at some point we have to cut over to this... so I think its expected we might hit a few snags... but we are probably also fixing a few bugs we just dont know about in the test infrastructure at the same time. -- lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
