At the risk of de-railing the conversation, is there an option to move to git for Apache Foundation projects such as River? I was long a big proponent of SVN but I'm now thoroughly converted and can't help but think this situation wouldn't have occurred if git were in use. (Yes, it's possible to do a bunch of commits on master, but it's not the usual practice.)
-j On Sat, Apr 6, 2013 at 7:25 PM, Greg Trasuk <[email protected]> wrote: > > > The "2.2" branch is very clean. It starts from release in 2011. Since > then, Dennis applied RIVER-417, added poms for listing at Maven Central, > and applied the Levels fix. I've applied RIVER-149, and that's it. > > A few days ago, I set out to see what else from the trunk should be > rolled in for a "minimal" release. In particular, I wanted to include > the fix for RIVER-149 which I did a while ago, because it fixes a > problem with the container work I've been doing separately. But I also > figured we might want to include non-controversial fixes. > > Before then, I did a 'svn diff', but it appears that the vast majority > of files have at least cosmetic changes (may be tabs or something), > because I got just about every file in the repository. > > See below for the list of changes that svn says have been applied to the > trunk since the release. I started going through all the revisions to > see what they were, by doing 'svn diff ../trunk -c XXX' where x is the > revision number (perhaps there's a non-manual way to do this). As you > can see, I didn't get too far before I started thinking that we'd better > do some strategic thinking. So I just merged in: > > r1211940 - RIVER-149 Fixes > r1140819 - Update build documentation. > > Back to the changes in trunk? > > To see what's gone on since 2.2.0, run the following: > > svn log https://svn.apache.org/repos/asf/river/jtsk/trunk -r > 1137621:HEAD > > I want to be very careful here because I don't want to sound like I'm > criticizing anyone. I know that Peter, especially, has done a lot of > work on the code. > > Having said that, as an observation and not a value judgement, I have to > say that I'm not confident about the state of the trunk. There have > been too many changes since a release, both to the main code and the > test code. There are radical changes to the security policy provider > (for perceived concurrency issues and also for revokable grants, I > think). Much cleaning, deleting, reorganizing. Many alterations > suggested by FindBugs. Replacement of string concatenation by > StringBuilder. Something about reference collections, which adds a jar > file that I can find no information on. Additions of 'dnsjava name > service provider'. Changes to tests that fail because of a > ConcurrentPolicyProvider. Changes to PreferredClassLoader to supposedly > improve concurrency. More changes to tests. Adding generics. Many > changes to tests to fix test failures. > > A lot of the changes look to me, like thrashing on problems. Now I > realize that chasing concurrency bugs can be a long game of > "whack-a-mole", but I see a lot of uncertainty and thrashing at solution > attempts. And I don't recall anyone reporting concurrency problems in > the field. And the first set of changes in there is a hell-of-a-long > list of "incremental merge of concurrent policy items". > > Short answer - for now I think we ought to test and release "2.2.1" from > the "2.2" branch. This branch includes the Level fixes and RIVER-149 > fix and not much else. It fixes the immediate problem that users have > reported, the system doesn't run with JDK7. > > List of longer-term reccommendations to follow. This message is > already in tl;dr territory. > > Cheers, > > Greg > > > > Changes to the trunk since 2.2.0 > ========================= > N r1128239 Added rat_reports.sh. Superseded > Y r1140819 Updated minimum Java version in build.html > Y r1211940 Fix RIVER-149 > N r1213641 River-265 Fix for unlucky caching as requested. River-401 > Changed to utilise URI in place of URL in map's and arrays to avoid > unnecessary DNS lookups. > r1213675 RIVER-401 Fix null pointer. Seems to be related to above. > r1222914 Fix exception cast and reset interrupt status. > Y r1224722 Fix JDK7 compile errors (inner class private field > accessibility) > Y r1227948 Commit msg says "RIVER-402 Fix null pointer exception. Looks > like JDK7 inner class private field accessibility stuff. > r1231478 Fix RIVER-403. DGC Leaks threads. > N r1231673 Reverted common.xml to trunk version. This is superseded by > dreedy's commit on 20130403. > N r1231675 Changed common.xml. As above. > N r1238468 Changed common.xml. As above. > Y r1241254 Propagate cause of interrupt. Very minor change to assist > service developers during debugging. > r1290906 Prepare for merge 2nd try. What? > r1290925 Incremental merge of concurrent policy items. > r1290926 Incremental merge of concurrent policy items. > r1290929 Continuing merge of concurrent policy items. > r1290940 Continuing incremental merge. > r1290947 Continuing concurrent policy merge > r1290948 Continuing concurrent policy merge > r1290949 Continuing concurrent policy merge > r1290965 Completion of concurrent policy merge (replace trunk). > r1290982 Minor post-merge changes for above. > r1291177 Removed source/target overrides in javac-cmd in build.xml > (JDK7?) > r1291182 Up 5 to 6 in javadoc.source property > r1301927 Cleaning, deleting, reorganizing > r1301929 Cleaning, deleting, reorganizing > r1302036 Cleaning, deleting, reorganizing > r1302083 Cleaning, deleting, reorganizing > r1302114 Deleted failing test, it was no longer relevant, tested > Delegate Security Manager functionality, which is now disabled. Reduced > the number of Integer, Long, Float, Char etc objects created, by using > valueOf instead of new. Fixed minor bugs found with FindBugs - some > string concatenations in loops outstanding > r1302267 Deleted failing test, it was no longer relevant, tested > Delegate Security Manager functionality, which is now disabled. Reduced > the number of Integer, Long, Float, Char etc objects created, by using > valueOf instead of new. Fixed minor bugs found with FindBugs - some > string concatenations in loops outstanding > r1302364 Reduced the number of Integer, Long, Float, Char, Short, etc > objects created, by using valueOf instead of new. Replaced string > concatenation in loops with StringBuilder. Fixed some bugs reported by > FindBugs. > r1303195 Fixed bug in Reggie, when random number returns > Integer.MIN_VALUE, then Maths.abs returns a negative number. Fixed a > classpath issue in the qa suite, caused by separating reference > collections. > r1309816 Added missing ASF license header. > r1309818 Updated rat version. > r1332577 Add doap.rdf file > r1337773 Add reference-collections to class path in two qa tests. > r1338673 Session class delayed instantiation in jdk1.6 caused > SecurityException because proxy ProtectionDomain was on the stack. This > caused some jtreg tests to fail, small fix, the bug doesn't exist in any > releases. > r1344606 Added netbeans onebigjar project. > r1344639 forced default compile options in project.properties > (onebigjar) > r1344736 added proper label (onebigjar). > r1355351 Refactoring for release, clean up and decrease size of new > public api. Separated RemotePolicy implementation from > DynamicPolicyProvider. Version numbers and documentation still requires > update prior to release. > r1355851 Refactoring for release, clean up and review new public api, > sanity check and remove unnecessary methods. Added dnsjava name service > provider to handle reverse dns lookup and to provide concurrent dns > lookups. Updated reference-collections, these were updated to avoid > calling hashCode during initialisation of Timed references and temporary > referrers, this helped reduced SocketPermission.hashCode calls that > caused reverse lookups and recursive permission checks that cause stack > overflow in the CombinerSecurityManager. Two tests are failling due to > a change to ConcurrentPolicyFile, now only privileged domains are > returned by getPermissions(CodeSource) and all other instances are > diverted to the java.security.Policy superclass which returns an empty > PermissionCollection this is to avoid checking permissions twice. > r1355852 Refactoring for release, clean up and review new public api, > sanity check and remove unnecessary methods. Added dnsjava name service > provider to handle reverse dns lookup and to provide concurrent dns > lookups. Updated reference-collections, these were updated to avoid > calling hashCode during initialisation of Timed references and temporary > referrers, this helped reduced SocketPermission.hashCode calls that > caused reverse lookups and recursive permission checks that cause stack > overflow in the CombinerSecurityManager. Two tests are failling due to > a change to ConcurrentPolicyFile, now only privileged domains are > returned by getPermissions(CodeSource) and all other instances are > diverted to the java.security.Policy superclass which returns an empty > PermissionCollection this is to avoid checking permissions twice. > r1358131 Fixed failing junit tests caused by change to > ConcurrentPolicyFile.getPermissions(CodeSource) method that now only > returns Permissions for privileged CodeSource and delegates up to the > super class java.security.Policy if the CodeSource is not privileged. > r1358143 seems to be some (deleted reference-collections.jar) > r1358709 Alter tests that fail due to ConcurrentPolicyFile delegating up > to java.security.Policy.getPermissions(CodeSource) when CodeSource is > found not to have AllPermission. Only CodeSources that are privileged > have Permissions returned that contains AllPermission. This is an > optimisation that complies with java.security.Policy. > r1359548 URI spaces in codebase strings caused problems with Windows > platforms - fixed. Removed calls to Thread.yield(). > r1360043 > r1360396 > r1361523 > r1361645 > r1361646 > r1361661 > r1361671 > r1362432 > r1362433 > r1362435 > r1362452 > r1362463 > r1362797 > r1362940 > r1363295 > r1363313 > r1364250 > r1364614 > r1366641 > r1366657 > r1366659 > r1367884 > r1367889 > r1369328 > r1369509 > r1369512 > r1369513 > r1369533 > r1369538 > r1369539 > r1369541 > r1369570 > r1369573 > r1369578 > r1369666 > r1369771 > r1370679 > r1371049 > r1371855 > r1373770 > r1379716 > r1379717 > r1379720 > r1379725 > r1379730 > r1379873 > r1384715 > r1384716 > r1384728 > r1384729 > r1384733 > r1384734 > r1384740 > r1384792 > r1384812 > r1385061 > r1385068 > r1385070 > r1385072 > r1385073 > r1385083 > r1385085 > r1388003 > r1389755 > r1389763 > r1389766 > r1389804 > r1389823 > r1392387 > r1393401 > r1393420 > r1393421 > r1393422 > r1393979 > r1394412 > r1394431 > r1394432 > r1394434 > r1394435 > r1394437 > r1394438 > r1395185 > r1395234 > r1395235 > r1396151 > r1396153 > r1396157 > r1396166 > r1396173 > r1396177 > r1396180 > r1396183 > r1396187 > r1396193 > r1396198 > r1396199 > r1396240 > r1396251 > r1396254 > r1396303 > r1397599 > r1397600 > r1397613 > r1397824 > r1398558 > r1398721 > r1398725 > r1398739 > r1398740 > r1400681 > r1400842 > r1400937 > r1402752 > r1402753 > r1402754 > r1402755 > r1402756 > r1402757 > r1402758 > r1402759 > r1402772 > r1402959 > r1402960 > r1402961 > r1402989 > r1403001 > r1404526 > r1404527 > r1404528 > r1404531 > r1404901 > r1404907 > r1404911 > r1404913 > r1406894 > r1406926 > r1406927 > r1407017 > r1407431 > r1415845 > r1444164 > r1444556 > r1444557 > r1449248 > r1455692 > > On 2013-04-06, at 11:22 AM, Dan Creswell <[email protected]> wrote: > > > On 6 April 2013 14:44, Dennis Reedy <[email protected]> wrote: > > > >> > >> On Apr 6, 2013, at 532AM, Dan Creswell wrote: > >> > >>> Right so we're into brutal tradeoffs aren't we? > >>> > >>> It's beginning to smell like none of the available branches are > suitable > >>> for doing releases from. So we need a branch that is. > >> > >> AFAIK we are going to be releasing 2.2.1 from the 2.2 branch. Once > >> everything passes muster (Greg is running tests) we will tag the > branch > >> 2.2.1 and release. > >> > >>> > >>> i.e. We shouldn't just pick a branch we have, we should get one > sorted > >> and > >>> right now. > >>> > >>> What are our chances of pulling just qa changes out of > qa-refactoring? > >> Have > >>> we at least got changesets that don't mix concurrency fixes with > anything > >>> other than concurrency related changes to tests? > >> > >> You are talking 2.3.0 here? I though qa-trunk was being used for > that? > >> > >> > > Peter is having some comms trouble looks like so I'll leave it at an > open > > question: > > > > Have we got a shared, agreed view of what unreleased code changes are > in > > which branch? > > > > > >> Dennis > > >
