river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Review-then-commit. Was: Re: 2.2 Release status
Date Sat, 27 Apr 2013 01:41:58 GMT


Hi all:

Peter brings up an excellent point here, something that I've found
troubling in this release process.  It is exceedingly difficult to
identify what changes have been made to the code, and why, or to trace
changes to JIRA issues.  By extension it's very hard to identify which
revisions have been or should be applied to a branch, and what bugs have
been fixed in a branch.

Just throwing this out for discussion - I'm coming around to the view
that we should adopt a policy of review-then-commit for changes to the
trunk and any release branches. 

I'm thinking that when someone does a bug fix or some work on a feature,
we should:

- do that work on a branch (call this the 'working' branch for this
discussion)
- package that work as either a patch or a list of revisions to merge
- put that package into a JIRA issue (which may already exist if we're
doing a bug fix).
- identify which branches the patch should be applied to
- review, discuss, and vote on the patch in the JIRA issue
- then apply the patch to those branches, referencing the JIRA issue in
the commit messages
- ideally, terminate the working branch.  Future work proceeds on a new
branch from the trunk.

That way, it would be easy to trace changes in the trunk and release
branches, and hence to generate an accurate release notice.

Also, I'd suggest that the "FIX_VERSION" field in JIRA belongs to the
release manager for a given release - he or she will update the field in
the requisite issues as part of the release process.

Your thoughts?  Anyone familiar with any other projects' practices?

Greg Trasuk.


On Fri, 2013-04-26 at 16:58, Peter Firmstone wrote:
> Checked RIVER-[404], the jtreg test certs still fail.
> 
> It's been fixed in trunk, we need to remove it from the release notes 
> for 2.2.1
> 
> I don't think River-[403] or River-[417] made it into 2.2.1 either.
> 
> I think these issues were marked as completed as part of a previous 
> release process that was left unfinished.  
> 
> River-[403] really needs to be included though.
> 
> Regards,
> 
> Peter.
> 
>  *** Start test: Sat Apr 27 06:46:43 EST 2013
>     [jtreg] Test 1: TestRMI$TestClientSubjectAfterSwitchConstraints:
>     [jtreg] FAIL: Unexpected exception: java.lang.IllegalStateException: 
> no object exported via this exporter
>     [jtreg]     at 
> net.jini.jeri.BasicJeriExporter.unexport(BasicJeriExporter.java:661)
>     [jtreg]     at 
> TestRMI$TestClientSubjectAfterSwitchConstraints.run(TestRMI.java:182)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:185)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:130)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:143)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:99)
>     [jtreg]     at TestRMI.main(TestRMI.java:53)
>     [jtreg]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>     [jtreg]     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>     [jtreg]     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     [jtreg]     at java.lang.reflect.Method.invoke(Method.java:585)
>     [jtreg]     at 
> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>     [jtreg]     at java.lang.Thread.run(Thread.java:595)
>     [jtreg]
>     [jtreg] Test 2: TestRMI$TestUnexportInServerImpl: force=true
>     [jtreg] FAIL: Unexpected exception: java.rmi.server.ExportException: 
> listen failed; nested exception is:
>     [jtreg]     net.jini.io.UnsupportedConstraintException: Problem with 
> certificates: CN=serverDSA, C=US
>     [jtreg] java.security.cert.CertificateExpiredException: NotAfter: 
> Mon Sep 05 00:24:12 EST 2011
>     [jtreg]     at 
> com.sun.jini.jeri.internal.runtime.BasicExportTable.export(BasicExportTable.java:84)
>     [jtreg]     at 
> net.jini.jeri.BasicJeriExporter.export(BasicJeriExporter.java:603)
>     [jtreg]     at TestRMI$TestUnexportInServerImpl.run(TestRMI.java:240)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:185)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:130)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:134)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:143)
>     [jtreg]     at UnitTestUtilities.test(UnitTestUtilities.java:99)
>     [jtreg]     at TestRMI.main(TestRMI.java:53)
>     [jtreg]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>     [jtreg]     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>     [jtreg]     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     [jtreg]     at java.lang.reflect.Method.invoke(Method.java:585)
>     [jtreg]     at 
> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>     [jtreg]     at java.lang.Thread.run(Thread.java:595)
>     [jtreg] Caused by: net.jini.io.UnsupportedConstraintException: 
> Problem with certificates: CN=serverDSA, C=US
>     [jtreg] java.security.cert.CertificateExpiredException: NotAfter: 
> Mon Sep 05 00:24:12 EST 2011
>     [jtreg]     at 
> net.jini.jeri.ssl.SslServerEndpointImpl$SslListenEndpoint.checkCredentials(SslServerEndpointImpl.java:726)
>     [jtreg]     at 
> net.jini.jeri.ssl.SslServerEndpointImpl$SslListenEndpoint.listen(SslServerEndpointImpl.java:658)
>     [jtreg]     at 
> com.sun.jini.jeri.internal.runtime.Binding$2.run(Binding.java:92)
>     [jtreg]     at java.security.AccessController.doPrivileged(Native 
> Method)
>     [jtreg]     at net.jini.security.Security$5.run(Security.java:543)
>     [jtreg]     at java.security.AccessController.doPrivileged(Native 
> Method)
>     [jtreg]     at 
> net.jini.security.Security.doPrivileged(Security.java:540)
>     [jtreg]     at 
> com.sun.jini.jeri.internal.runtime.Binding.activate(Binding.java:89)
>     [jtreg]     at 
> com.sun.jini.jeri.internal.runtime.BasicExportTable.getBinding(BasicExportTable.java:221)
>     [jtreg]     at 
> com.sun.jini.jeri.internal.runtime.BasicExportTable.access$100(BasicExportTable.java:46)
>     [jtreg]     at 
> com.sun.jini.jeri.internal.runtime.BasicExportTable$LC.addListenEndpoint(BasicExportTable.java:247)
>     [jtreg]     at 
> net.jini.jeri.ssl.SslServerEndpointImpl.enumerateListenEndpoints(SslServerEndpointImpl.java:568)
>     [jtreg]     at 
> net.jini.jeri.ssl.HttpsServerEndpoint.enumerateListenEndpoints(HttpsServerEndpoint.java:835)
>     [jtreg]     at 
> com.sun.jini.jeri.internal.runtime.BasicExportTable.export(BasicExportTable.java:81)
>     [jtreg]     ... 14 more
>     [jtreg] Caused by: java.security.cert.CertificateExpiredException: 
> NotAfter: Mon Sep 05 00:24:12 EST 2011
>     [jtreg]     at 
> sun.security.x509.CertificateValidity.valid(CertificateValidity.java:256)
>     [jtreg]     at 
> sun.security.x509.X509CertImpl.checkValidity(X509CertImpl.java:570)
>     [jtreg]     at 
> sun.security.x509.X509CertImpl.checkValidity(X509CertImpl.java:543)
>     [jtreg]     at 
> net.jini.jeri.ssl.Utilities.checkValidity(Utilities.java:774)
>     [jtreg]     at 
> net.jini.jeri.ssl.SslServerEndpointImpl$SslListenEndpoint.checkCredentials(SslServerEndpointImpl.java:698)
>     [jtreg]     ... 27 more
> 
> Greg Trasuk wrote:
> > Hi all:
> >
> > This build https://builds.apache.org/job/river-2.2-qa-jdk7/4/ says it
> > failed, but if you look closely at the console output, all the testing
> > passed.  There was a configuration error (mine) in the archiving results
> > post-build step. There's another build scheduled which should show a
> > complete "pass" result.  Unfortunately, as we know, the test run is
> > about 16 hours.  And we're not the only project with long test runs, so
> > there's a substantial wait time before the run gets onto an executor
> > machine (just as an aside, I'm looking into setting up a Jenkins
> > instance of my own to run test builds in the future.  Perhaps others
> > should think of doing the same thing).  In any case, given the minimal
> > changes from 2.2, I'm now comfortable going forward with a release.
> >
> > I'm currently building the 2.2.1 release candidate and am thinking of
> > calling for a vote shortly.  Should I go straight to the vote, or do
> > people want to review and independently test the 2.2 branch first?
> >
> > Not that I'm calling a vote yet, but as I'm typing, I see the release
> > candidate has finished uploading to
> > http://people.apache.org/~gtrasuk/river/, so if you want to have a look
> > at it, go ahead, and let me know if there's any issues.  I will mention
> > that if you read the RAT reports, the "qa_jtreg" report names 224 files
> > without license headers.  These are ".policy" and other configuration
> > files with little creative content.  Further, they were in the previous
> > release as approved by the Incubator, so I think we're on safe ground
> > here, although they probably should have license headers added in the
> > trunk at some point.
> >
> > Also, as a point of order, normally a vote would run for 72 hours. 
> > Given that the weekend is coming up, I'm inclined to extend that to 96
> > hours.  Opinions?
> >
> > Cheers,
> >
> > Greg Trasuk.
> >
> >
> >
> >   


Mime
View raw message