river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Next steps after 2.2.1 release
Date Sun, 07 Apr 2013 15:37:11 GMT

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


Mime
View raw message