Also failure occurs on hudson, that I can't repeat locally, so yes I sometimes perform experiments, but the tests always pass locally before I commit changes.
In any case, the code will remain available in qa_refactor after I finish the work, what the community does with it is up to the community. Peter. ----- Original message ----- > 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 > > >
