Re: Next steps after 2.2.1 release

Greg, You need to spend some more time figuring out why those tests are failing, that isn't normal, when 280 tests fail, there's usually something wrong with configuration. The qa test suite just isn't that brittle ;) The tests that fail due to concurrency errors don't fail often, we're ta

Re: Next steps after 2.2.1 release

Performance is very difficult to determine with simple tests, so what I've been doing is using qa suite stress tests that run for several minutes for my benchmarks, because I test on different hardware, the individual results are only comparable on that hardware. I run jvisualvm to identify ho

Build failed in Jenkins: river-qa-refactor-jdk7 #54

See Changes: [peter_firmstone] Changes to mahalo for safe publication, added Starter to TxnManagerImpl and improved atomicity, fields made final and volatile all tests passing on sparc. Changes to CombinerSecurityManager and Con

Re: Next steps after 2.2.1 release

On 4/6/2013 7:26 PM, Greg Trasuk wrote: ... Once we have a stable set of regression tests, then OK, we could think about improving performance or using Maven repositories as the codebase server. ... I think there is something else you need before it would be a good idea to release any changes

Re: Next Release

At the risk of de-railing the conversation, is there an option to move to git for Apache Foundation projects such as River? I was long a big proponent of SVN but I'm now thoroughly converted and can't help but think this situation wouldn't have occurred if git were in use. (Yes, it's possible to do

Next steps after 2.2.1 release

OK, so in my last message I talked about how (speaking only for myself) I'm a little nervous about the state of the trunk. So what now? Problems we need to avoid in this discussion: - - Conflation of source tree structure issues wi

Re: Next Release

The "2.2" branch is very clean. It starts from release in 2011. Since then, Dennis applied RIVER-417, added poms for listing at Maven Central, and applied the Levels fix. I've applied RIVER-149, and that's it. A few days ago, I set out to see what else from the trunk should be rolled in for a

Re: Next Release

Just to clarify: Dennis & Greg are using the 2.2.0 branch from last release to fix Levels and release 2.2.1 trunk started failing tests after some unrelated changes exposed synchronization errors in the qa tests, since then skunk/qa-refactoring is being used to fix synchronization issues befo

Re: Next Release

On 6 April 2013 14:44, Dennis Reedy wrote: > > On Apr 6, 2013, at 532AM, Dan Creswell wrote: > > > Right so we're into brutal tradeoffs aren't we? > > > > It's beginning to smell like none of the available branches are suitable > > for doing releases from. So we need a branch that is. > > AFAIK w

Re: Next Release

On Apr 6, 2013, at 532AM, Dan Creswell wrote: > Right so we're into brutal tradeoffs aren't we? > > It's beginning to smell like none of the available branches are suitable > for doing releases from. So we need a branch that is. AFAIK we are going to be releasing 2.2.1 from the 2.2 branch. Once

[Fwd: Re: Next Release]

I feel like strangling the phone email client about now ;) --- Begin Message --- Ignore this message, my mail client sent it days late. - Original message - > Not a good idea, the qa-refactoring branch was created recently to address the > concurrency bugs in trunk. > > - Original mess

Re: svn commit: r1464321 - in /river/jtsk/branches/2.2: ./ asm/ qa/ qa/doc/ src-doc/static/ src/com/sun/jini/resource/ src/net/jini/config/ src/net/jini/export/

On 4/6/2013 2:04 AM, Dan Creswell wrote: On 6 April 2013 04:43, Dennis Reedy wrote: On Apr 5, 2013, at 956PM, Peter wrote: We can't afford to hold up 2.3.0 much longer, the 2.2.0 release has numerous synchronization bugs, these will become more apparent on multicore hardware. The longer w

Re: Next Release

Right so we're into brutal tradeoffs aren't we? It's beginning to smell like none of the available branches are suitable for doing releases from. So we need a branch that is. i.e. We shouldn't just pick a branch we have, we should get one sorted and right now. What are our chances of pulling jus

Re: Next Release

We created a "qa-refactoring" branch for concurrency work On 3 April 2013 22:10, Peter wrote: > Not a good idea, the qa-refactoring branch was created recently to address > the concurrency bugs in trunk. > > - Original message - > > > > On Apr 2, 2013, at 750AM, Peter Firmsto

Re: svn commit: r1464321 - in /river/jtsk/branches/2.2: ./ asm/ qa/ qa/doc/ src-doc/static/ src/com/sun/jini/resource/ src/net/jini/config/ src/net/jini/export/

On 6 April 2013 04:43, Dennis Reedy wrote: > > On Apr 5, 2013, at 956PM, Peter wrote: > > > We can't afford to hold up 2.3.0 much longer, the 2.2.0 release has > numerous synchronization bugs, these will become more apparent on multicore > hardware. The longer we wait the more likely they'll pre