river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: test failure repeatability
Date Tue, 02 Apr 2013 11:50:53 GMT
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.

>   Additionally, what are the steps necessary to create a release?

   1. First create a branch of 2.2.0, call it 2.2.1.
   2. Developers will need to update their developer keys in the keys file.
   3. Backport sensible synchronization fixes for existing classes
      (don't get carried away, just essentials).
   4. Definitely fix LookupLocator serialization which was accidentally
      broken (similar to Levels an additional field was added that
      should have been transient), look at the qa-refactoring release
      for the fix, which is backward compatible with all releases.
   5. Run the rat report tool, there should be a shell script for that,
      it checks for licence compliance.
   6. Increment version numbers (find 2.2.0 and replace with 2.2.1, but
      don't replace all occurrences of 2.2.0, this has to be inspected
   7. Update the release documentation.
   8. Post pre release artifacts for wider community testing.
   9. Wait about two weeks for feedback.
  10. Then vote on the release artifacts.
  11. Publish the artifacts.
  12. I have some handwritten notes about the release process, they're
      about 200km away from where I'm presently working, I should be
      able to access them on the weekend.

This release will probably only be supportable on Linux and Solaris, 
Windows only passed all tests recently, Windows users will want to wait 
until we sort out the concurrency issues (ironically I haven't 
reproduced any concurrency test failures on Windows, maybe the Windows 
jvm is less aggressive with optimisations, or its the hardware being 

For now I'm going to continue focusing my efforts on the qa-refactoring 
branch, as it's been over three years since 2.2.0 was released, I'm 
close and don't want to  delay 2.3.0 much longer.  This is a big release 
which has culminated in 3 years of ongoing efforts.

In future I'd like to break River up into separate smaller components 
that are far easier to release, I don't think I can do it again for 
another 3 years, but we can save that discussion until after we've 
released so we don't get distracted.   I would like to see a more agile 
release process.



View raw message