+1 for 2.2.1 release. +1 to investigate modular build options. -1 for broad brush proposal based on incorrect assumptions.
I'm concerned people are jumping to conclusions and making incorrect assumptions, the understanding of the current build is clearly lacking: 1. The qa suite can be run against any other build by changing the RIVER_HOME property. It's already a separate build, it's not coupled. It is where it is for convenience and ease of use for new developers. 2. Windows passes all tests with trunk and qa-refactoring. We have RFC3986 compliant URI paths that can handle spaces and illegal characters. Yes these builds are more jini standards compliant than the so called clean 2.2 branch. 3. The quality of the code in trunk and qa-refactoring is far superior to the 2.2 branch. 4. Branching a new trunk off 2.2, because it's "clean" is insufficient justification and discards three years of hard work. 5. The integration tests cannot be replaced by junit, all test frameworks in use are of equal importance. 6. I have not seen one question regarding the code, this has been developed in collaboration, with multiple discussions on trunk and with standards compliance testing over the last 3 years. Furthermore: I reiterate; I am confident the latest code is superior to 2.2 and is API compatible. My next task is to refactor or remove TaskManager. Once this is done I'll release 2.3.0 I refuse to participate in a new trunk branched off 2.2, it is doomed to fail, discarding 3 years of synchronization fixes, concurrency improvements as well as fixes for fundamental platform issues like over reliance on DNS is engaging in an act of project vandalism. Developers are free to maintain a 2.2 branch, I'm not against that. In fact it would allow a transition period. People need to think very carefully before making rash decisions, remember your actions are on public display, do more research, choose your next move wisely. Regards, Peter Firmstone. ----- Original message ----- > > On Sun, 2013-04-07 at 10:18, Dennis Reedy wrote: > > On Apr 6, 2013, at 1026PM, Greg Trasuk wrote: > > > > > > Proposal > > > ------------ > > > > > > 1 - Release version 2.2.1 from the 2.2 branch. > > > > +1 for this, we really need to get this done, and get this done before > > the end of the month. > > Agreed. I was sincerely hoping for this last month. > > > > > > > > 2 - Create a separate source tree for the test framework. This > > could come from the "qa_refactor" branch, but the goal should be to > > successfully test the 2.2.1 release. Plus it should be a no-brainer > > to pull it down and run it on a local machine. > > > > I would actually like to have the (at least) unit tests part of the > > same source tree. I can see integration tests being in a separate > > module, but it should not be a separate source tree. When River gets > > built we should automatically run unit tests. Integration testing can > > happen as a separate step. > > > > Unit tests in the main source tree are fine. But I feel like we've > reached the point we're at because we don't have a clean separation > between the code and the integration/regression tests. Hence I'd like > to make sure that there's a test package separate from the development > branch, so that we can have confidence that the core functionality. > > > Additionally, I also dont see why we need a "test framework" per se. > > Why not just use JUnit or TestNG? > I don't see a problem with streamlining the tests, once the integration > and regression tests are split out. If we're going to develop/modify > tests, I want to make sure we can run them against a known-good release > build. Only then can we apply them to a "probably good" release > candidate. Seems to me that splitting out the acceptance testing is a > convenient way to allow for separate governance on the tests and core > functionality. > > By the way, I think a part of me just died when I used the "g-word" > above :-) > > > > > > 3 - Release 2.2.2 from the pruned jtsk tree. Release 1.0.0 of the > > test framework. > > > 4 - Pull out the infrastructure service implementations (Reggie, > > Outrigger, Norm, etc) from the core into separate products. Release > > 1.0.0 on each of them. Release 2.2.3 from the pruned jtsk tree. > > > > Yes, we need to trim up project. Once 2.2.1 is released I had planned > > on branching and starting a modular (maven-ized) project. I really do > > not know what the state of trunk, qa-trunk (or any other branch) so > > starting with 2.2 as the baseline seems more stable to me. > > That's about where I'm coming from too. > > > > > Regards > > > > Dennis >
