This will not be productive. Either way you will get to the same results as having qa as a basis for the future, in some form if what exists now.
This JMM stuff related to the 1.5 changes in Java are very real and very serious issues. It should not be ignored nor suppressed as something that rarely is an issue. The removal of HashTable, Vector and lots of other HappensBeforeGenerators will completely break all kinds of previously functioning code. That's why stuff has mysteriously broken. It wasn't compliant to begin with and used side effects of other code to semi-function. Gregg Sent from my iPhone > On Jan 22, 2014, at 9:08 AM, Greg Trasuk <tras...@stratuscom.com> wrote: > > > I understand the sentiment, but I’m uncomfortable with the number of changes > that happened without much review between releases. Run the following > commands: > > svn diff https://svn.apache.org/repos/asf/river/jtsk/trunk > https://svn.apache.org/repos/asf/river/jtsk/branches/2.2 > > svn diff https://svn.apache.org/repos/asf/river/jtsk/skunk/qa_refactor/trunk > https://svn.apache.org/repos/asf/river/jtsk/branches/2.2 > > Note that much of the test code changed alongside the implementation code. > Also, if you look at the commit history, there’s a lot of experimentation and > cases where the code went down one path and then retreated. Unfortunately, I > think trunk and qa_refactor became experimental branches. No problem with > that, but it would be hazardous to just blindly merge them back. > > I think that there are so many changes that we’re best to treat the 2.2 > branch as “current” and then integrate the new code piece-by-piece with full > discussions, reviews and a fall-back plan. > > Cheers, > > Greg. > > > >> On Jan 22, 2014, at 9:30 AM, Dennis Reedy <dennis.re...@gmail.com> wrote: >> >> >>> On Jan 22, 2014, at 916AM, Greg Trasuk <tras...@stratuscom.com> wrote: >>> >>> >>>> On Jan 21, 2014, at 6:57 AM, Peter Firmstone <j...@zeus.net.au> wrote: >>>> >>>> >>>> If this proposal is supported, I'd also reccommend that trunk be reverted >>>> back to the 2.2 River branch, with the exception of Sim's work on >>>> ClassLoading, which should be included. >>>> >>>> Provided there is support, change trunk to review then commit without lazy >>>> concensus. >>>> >>>> I would finish the work on qa_refactor and solve the remaining >>>> multithreaded issues (on a longer lower pressure time schedule), the River >>>> community can then decide whether it wants to use code from qa_refactor on >>>> an as needed basis. I believe that the River community will find this >>>> code a useful reference for latent multithreaded bugs. >>>> >>> >>> I’m in favour of this approach. >> >> I'm not. I think trunk should contain the ongoing development of River. We >> have the 2.2 branch, I think 2.2 should stay there. I would like to see >> qa_refactor moved to trunk, have com.sun.jini namespace changed to >> org.apache.river and move to 3.0. >> >> Regards >> >> Dennis >
