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 13:50:47 GMT

On Sun, 2013-04-07 at 06:34, Peter Firmstone wrote:
> Oh, hang on, are you developing on Windows?  If so, it's not supported 
> in 2.2.0.
> 

OSX 10.8 in this case, although I also plan to run the test suite on
Windows XP32 and Win7-64.  Possibly also Solaris 10.  As I recall the
"Windows not supported" was primarily about spaces in the file path.  If
that's the case, then IBM's Websphere is not supported on Windows
either. I was planning to arrange for a space-free directory path. 
People have been running Jini on Windows since the dawn of time.

Greg.

> 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.
> >>
> >>
> >>
> >>   
> >
> >


Mime
View raw message