river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Next release (2.2.1)?
Date Mon, 22 Apr 2013 13:25:19 GMT

----- Original message -----
> Hi all:
> I've been testing the 2.2 branch locally in a few environments, and I
> haven't seen anything that looks like anything but local configuration
> issues.  So I'd like to move forward with the release process (steps
> will be described below).  I have few questions first...
> Levels fix - Dennis - I thought I saw a while ago that we didn't have
> the most recent "com.sun.jini.logging.Levels" fix in the 2.2 branch.
> Could you check on that, and commit the code that we should release
> with?
> Testing - I'm thinking that we should setup one or two Jenkins jobs to
> test out the "2.2" branch.  However, that is likely to conflict with the
> testing that Peter is doing on his "qa_refactor" branch.  Does Jenkins
> have a way of arbitrating access so that the test runs will not be
> concurrent, thus avoiding any port conflicts?  

Don't worry too much about conflicts, a second test run on the same node fails quickly and
obviously.  There's a global lock, but unfortunately it prevents concurrent runs on separate
nodes.  Perhaps you might be able to figure out how to create some new test run locks for

If you want to set up a jenkins test build, copy an existing build, change the name and svn
target url.

Anyone have any opinions
> as to whether we actually need Jenkins jobs, or are we comfortable with
> a few of us testing the branch locally?

Depends on the number of changes, I try to test as widely as possible on as many architectures
as possible, but with so few changes in 2.2.1 it's probably not worth the effort.

Do try and run the jtreg tests if you can though, from memory there a 5 test failures that
relate to kerberos, a squid proxy server and an unknown address.  It's possible the SSL certificates
have expired, if so, copy them from trunk. 

It might be possible to write a test case using a custom objectoutputstream and objectinputstream
that substitutes Levels class names to check serial form compatibility.  MarshalledInstance
does this to convert from MarshalledObject without unmarshalling. 

> Process - As soon as we know we have the right Levels fix, and sort out
> our questions over testing, and (I would imagine) one or two of us have
> acceptable test results for the particular revision, then I'll tag the
> release and generate the release packages, which we can vote on.
> I'd kind of like to complete this process by the end of the month.
> Cheers,
> Greg.
> On Thu, 2013-03-28 at 15:14, Dennis Reedy wrote:
> > Hi,
> >
> > Was wondering how we are doing with getting the next release out the door? I'd
> > like to suggest that we move on this as soon as possible If there are issues
> > that do come up with the release, we can always release again.
> >
> > Regards
> >
> > Dennis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message