river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Next Release
Date Wed, 03 Apr 2013 14:30:22 GMT
Hi Dennis:

I think the suggestion was that we do a release branched off the 2.2.0
release with a bare set of patches moved over - primarily the Logging
fix and I think there was a change to one of the JRMP context classes
that I needed for the Surrogate container.  And then a release from the
qa_refactor branch a little bit later.

Personally I'd like to see some kind of release sooner rather than
later.  It's been a while.  I'll act as RM for a minimal release if we
can agree on doing that.

I'm planning on having a few cycles this afternoon to take a look at a
diff and see what-all changed, and if there was anything else that
should go into a minimal release.



On Wed, 2013-04-03 at 09:39, Dennis Reedy wrote:
> On Apr 2, 2013, at 750AM, Peter Firmstone wrote:
> > On 2/04/2013 7:51 PM, Dennis Reedy wrote:
> >> On Apr 2, 2013, at 338AM, Peter Firmstone wrote:
> >> 
> >>> The formatting didn't work out, I'll create a Jira issue to discuss.
> >>> 
> >>> Patricia's done a great job detailing the dependencies and issues with TaskManager's
Task implementations.
> >>> 
> >>> I recall a list discussion from the original Sun developers who had intended
to replace TaskManager, the runAfter method has issues.
> >>> 
> >>> Being so prevalent, it's quite possible that TaskManager is causing issues
and it might also explain why as performance improves more issues arise.
> >>> 
> >>> If a task completes before another task which it's supposed to runAfter
but isn't present in the queue; that could explain some issues.
> >>> 
> >>> I much prefer idempotent code myself.
> >>> 
> >>> This could take some effort to fix, any volunteers?
> >>> 
> >>> Dennis are you able to continue with your 2.2.1 branch release?
> >> At this point I am unsure what branch to base the 2.2.1 release off of.
> > 
> > The 2.2.0 release, it might benefit from backports of synchronization fixes that
improve correctness, but not performance, if some volunteers can diff the qa-refactoring branch
and the 2.2.0 branch, there are numerous simple synchronization fixes.
> I'd like to suggest we release from qa-trunk. With all the work thats been going on here,
I dont see back porting it to the 2.2 branch is meaningful. The delta is just too much.

View raw message