I'm of the opinion that this situation has occurred because of policy decisions by various developers in respect of what development and how much to do where. I don't think the current tooling has anything to do with those decisions nor do I believe git would've led to a different set of decisions.
Basically, either of git or svn have sufficient mojo to cope with the policies we're discussing. Would either enforce/encourage a particular set of policies that would make a difference? Doubtful. On 7 April 2013 05:08, Jeff Ramsdale <[email protected]> wrote: > 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 > > > > > > >
