river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Next steps after 2.2.1 release
Date Sun, 07 Apr 2013 10:34:11 GMT
Oh, hang on, are you developing on Windows?  If so, it's not supported 
in 2.2.0.

Peter Firmstone wrote:
> Greg,
> You need to spend some more time figuring out why those tests are 
> failing, that isn't normal, when 280 tests fail, there's usually 
> something wrong with configuration.  The qa test suite just isn't that 
> brittle ;)   The tests that fail due to concurrency errors don't fail 
> often, we're talking 3/10 you might get a failure (if you're lucky) 
> and likely, you won't see any failures on single core hardware.  The 
> Jenkins tests tend to be more likely to fail because they run 
> concurrent with other builds, in a busy network environment (sockets 
> in use etc), with lots of superfluous discovery processes going in the 
> background.
> If you need some help with the source tree, I'm quite familiar with 
> it, don't be afraid to ask questions.
> This is a big distribution, there is a lot of code, it is initially 
> difficult to find your way around, but patience will be rewarded.
> There are 3 test suites:
> 1. trunk/test
> 2. trunk/qa/src
> 3. trunk/qa/jtreg
> The first is the junit test suite, the second is the qa integration 
> test suite and tck, which simulates a network environment with all the 
> services, the last is the jtreg regression test suite.
> When you've done further investigation and better understand the code, 
> then we'll be in a better position for discussion, right now the 
> immediate focus should be on a 2.2.1 release.
> I'll switch to your branch and run the tests if you like.
> I'd also like to encourage you to look at the code in 
> skunk/qa-refactoring, it's well documented and should be easy to read, 
> I've followed Kent Beck's recommendations for code readability.
> I hope this helps.
> Regards,
> Peter.
> Greg Trasuk wrote:
>> OK, so in my last message I talked about how (speaking only for 
>> myself) I'm a little nervous about the state of the trunk.
>> So what now? 
>> Problems we need to avoid in this discussion:
>> -------------------------------------------------------------
>> - Conflation of source tree structure issues with build tool selection.
>> - Conflation of Maven build, Maven as codebase provider (artifact 
>> urls), and posting artifacts to Maven Central
>> - Wish lists of pet features
>> - Bruised egos and personal criticisms.
>> Issues I see, in no particular order:
>> ----------------------------------------------
>> - We've done changes both to the test framework and the code, and 
>> lots of them.  We should do one or the other, or small amounts of 
>> coevolution, if absolutely necessary.
>> - Really, I'd like to see a completely separate integration test, and 
>> have the TCK tests separated out again.
>> - The source tree is incomprehensible
>> - The tests appear to be awfully sensitive to their environment.  
>> Insofar as when I run them locally on an untouched source tree, I get 
>> 280 failures.
>> - There have been changes to class loading and security subsystems.  
>> These subsystems are core to Jini, and the changes were made to the 
>> existing source, so there's no way to "opt-out" of the changes.  I'd 
>> like to see radical changes be optional until proven in the field, 
>> where possible.  In the case of policy providers and class loaders, 
>> that should be easy to do.
>> - Similarly, it seems there have been some changes to the JERI 
>> framework.
>> - There are ".jar" files in our repository.  I'll stipulate that the 
>> licensing has been checked, but it smells bad.
>> Discussion
>> -----------------
>> I guess the biggest thing I'd like to see is stability in the test 
>> framework.  Perhaps it needs refactoring or reorganization, but if 
>> so, we need to be very careful to separate it from changes to the 
>> core functionality.
>> Next, I'd like for it to be easier to comprehend the source tree.  I 
>> think a good way to do that is to separate out (carefully) the core 
>> Jini package (basically the contents of jsk-platform.jar) and the 
>> service implementations.  There's no reason that we have to have one 
>> huge everything-but-the-kitchen-sink distribution.  That's just a 
>> holdover from how Sun structured the JTSK - It was literally a 
>> "starter kit".  To me it would be fine to have separate deliverables 
>> for the platform and the services.
>> While we're separating out the services, it might also be a decent 
>> time to implement Maven-based builds if we think that's a good idea.  
>> I'd start with Reggie.  It would also be a good time to get rid of 
>> the "com.sun.jini" packages.
>> Aside:  I'm personally ambivalent on Maven (which is to say I'm 
>> nowhere near as negative on it as I once was).  I do agree with 
>> Dennis, though, that the jars and appropriate poms need to be 
>> published to Maven Central.  There's no doubt that users will 
>> appreciate that.
>> Once we have a stable set of regression tests, then OK, we could 
>> think about improving performance or using Maven repositories as the 
>> codebase server.
>> I realize this won't be popular, but my gut feel is that we need to 
>> step back to the 2.2 branch and retrace our steps a little, and go 
>> through the evolution again in a more measured fashion.
>> Proposal
>> ------------
>> 1 - Release version 2.2.1 from the 2.2 branch.
>> 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.
>> 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.
>> 5 - Adopt a fixed release cycle.  Not sure if it should be quarterly 
>> or biennial, or whether it should be all products at once or 
>> staggered releases.  We'll need to discuss.
>> 6 - Then we can start making changes if necessary to the individual 
>> products.  And also try to deal with making it easier for new users 
>> to use the technology.
>> So there you go.  Opinions?
>> Greg Trasuk.

View raw message