+1 I'm in agreement with Dennis on this one. To me it makes sense to move River forward with a nice big bang "miracle upgrade". :-) And adopting this stuff in as a v3.0 seems like a good idea. I would like to see the results of the old test suites run against the new code and the other way around. I appreciate that they're not all going to pass either which way, but I can see the failure reports as being good starting points to dive into reviewing the code changes.
I agree that this is a big risk, but it's not like there are no ways out or back. Version 3.0.x can be released for bug fixes, or worst case, we post a message saying "Don't touch v3.0!" Also, people can also just chose not to upgrade. On Sun, Jan 26, 2014 at 12:33 AM, Gregg Wonderly <ge...@cox.net> wrote: > 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 > > >
