Just to clarify, the reversions fixed problems with merging, they were unrelated to tests.
When I fix a failing test, I first confirm it also passes on either other architectures or after repeated tests, or that changes made revealing the failure aren't directly related, then I inspect the code and fix any sync issues. I fix all sync issues found, even if it's unrelated to a test failure. I've also fixed instances of copy pasted code with an object the has the desired functionality. Yes, there are many changes, I'm currently working on replacing TaskManager in SDM, JoinManager and Reggie. Regards, Peter. ----- Original message ----- > > 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 >
