If people would prefer to vote on fewer bigger releases at the cost of internal compile-order dependencies, I can certainly do it that way, although I do think all 118 bundles in one go would still be too much for the PMC to digest. :)
On 29 Jun 2012, at 08:28, Guillaume Nodet <[email protected]> wrote:
They would be compilable, you just have to compile them in the right orderfrom the tags / source distributions.If you (the release manager) have been able to compile them, anyone whouses the same tags will be able to do so too. On Thu, Jun 28, 2012 at 11:18 PM, Holly Cummins < [email protected]> wrote:Wouldn't the bundles be testable, but not compile-able from source, since the 1.0.0 dependencies would only exist in the staging repository? Certainly if we could do everything in one shot it would make the process of getting everything out the door much faster ...On Thu, Jun 28, 2012 at 6:12 PM, Guillaume Nodet <[email protected]> wrote:I think you made a wrong assumption which is that the staging repo hasto be backed by a single svn revision (which is btw not really the case because it comes from several tags anyway). What I'd suggest is doing the api bundles release and have them uploaded to nexus, then upgrade the implementations and all other components to use those releases, commit, release those other projects, THEN, close the staging repo and call for a vote.So we'd have a single staging repo / vote with a set of testable bundlesin it.On Thu, Jun 28, 2012 at 6:45 PM, Holly Cummins <[email protected]> wrote:Hi Guillaume, Thanks for your comments. Here are some of my thoughts ... On Thu, Jun 28, 2012 at 3:19 PM, Guillaume Nodet <[email protected]>wrote:I think one problem, considering the current votes, is that it's really difficult to test anything. Releasing api bundles with no implementation to test is definitely not helping imo.I know what you mean about the testing, and I'm not totally sure what the best answer is. I know what I'm releasing comes from trunk, and is being tested by the Jenkins builds, so I'm pretty confident it worksin a real system. However being tested in more environments and bymore systems is obviously a Good Thing. I think the best way to testthe API bundles is with the current -SNAPSHOT bundles of theimplementation, either in something like the blog sample or some otherworking system. If we weren't moving from 0.x to 1.0 you could also test micro releases alongside existing impl bundles to ensure everything resolves and works as claimed.Holly, just a question: is there a specific reason why are you doing the release in multiple votes ? It would be simpler to just release everything in one go and wait for a longer time because there are more things to check, or at least, release the api + implementation so thatwe can actually try something. Just my 2 cents.I agree that this sort of 'extended incremental' release is a bit awkward, and I was wondering when someone would ask what on earth I was doing :). IMO it's the cleanest way to work with with release-by-bundle (which I know you disagree with). If I releaseeverything in one go, there's a problem with the dependencies between bundles. At the moment in trunk, almost every dependency is a SNAPSHOT dependency. In the past we've updated all bundles to use non- SNAPSHOT(but not yet released) versions in a branch, and I could even dosomething similar without using a branch by briefly having the trunkbuilds produce 1.0.0 artefacts. However, I think this creates a greater burden for testers. If there are compilation-orderdependencies between parts of a release which don't share a top- levelpom, everyone verifying a script has to compile them in the rightorder. I count 118 bundles to release, so that's a lot of bundles to get in the right order, and I didn't think any PMC member would want to try. :) I guess this could be automated with a verification scriptwhich either hardcodes or calculates the dependency graph, but it seemed to me like more work for everyone and more risk for the release. My hope was that if verifying individual mini-releases was easy enough, doing multiple ones wouldn't be a problem (and in fact would nicely distribute any effort, making it easier to vote). I know at this stage some of you are thinking "and *this* is why release by bundle is a bad idea!", and that's not really a debate Iwant to re-open. Among other things, I think any re-engineering of ourpoms at this stage will further delay the release.The good news is I believe this problem will almost entirely go awayfor 1.0.x and 1.x releases, because the impl bundle will, in most cases, depend on an *already* released version of its API bundle oranother Aries component. This means a bunch of related bundles could be released at the same time, without compile issues, or a meaningfulrelease really could consist of just a single bundle. That's true modularity and it should give both us and our users big benefits.On Mon, Jun 25, 2012 at 8:07 PM, Daniel Kulp <[email protected]> wrote:Honestly, with the change to using Nexus, the SHA1 and MD5 checks are completely pointless. Nexus generates them itself based on what's uploaded. The "is it a valid signature" part of the GPG testing isalsopointless as Nexus won't let you close the repo unless the signaturesarevalid. The only check you really need to do is to make sure the keythatwas used is "trusted" by you. (aka: was it really Holly whodeployed thoseartifacts) So the monontonous parts of checking that stuff isreallyirrelevant at this point. (providing we trust that infra has Nexussufficiently locked down and secure)I actually don't have a big issue with the difficulting in gettingvotes.I'm involved in another community that has a PMC that is easily 4times thesize of this one, yet we still have difficulting getting votes there. While not ideal, life events can cause priority shifts and such sopeoplemay not be able to be as responsive.My bigger problem is that the entire per bundle release process andsymanticversioning crap has put a HUGE burden on the release manager. Thatmakesit much harder to get quality releases out and makes it less likelythatanyone will step up to get "minor fixes" released. The only reason I stepped up with the 0.3.1 bp stuff is that *MY* customers are being affected by it. Like wise for the proxy stuff. If *my* customerswerenot affected, I don't think I would have spent the time and effort.Ifthe process for getting fixes and releases out to users was smallerandeasier, I have no problem doing them. For CXF, we do full releaseson 3branches every other month or so. But that's because it's EASY todo.If it was up to me, I'd toss out the entire versioning thing with 1.0and goback to per module versioning thing. So my fix to proxy would have involved checking out all of "proxy", fixing it, and releasing all ofproxyas a proxy "0.3.1", even the modules that haven't changed. It'sjust ahuge hassle to track down which bundles have changed, which haven'twhichversion numbers need to be updated, etc.... If it's not quick andeasy todo releases as a release manager, very few people are going to stepup to doit. It may not be 100% "proper OSGi", but IMO, getting fixes andsuch tothe users is more important than that. But that's my opinion. Dan On Saturday, June 23, 2012 03:27:07 PM Holly Cummins wrote:Hi all,Now that Jeremy's taken the time to write up our release verificationprocess, I'd like to propose we change it. :) I think it's tooonerouson the pmc, which therefore also inhibits our ability to beresponsiveto our users.------------------------------- Why what we have isn't working forthecommunity ------------------------------- I believe our users would like more frequent releases. We've had several keen requests and tweets and comments on the aries-user mailing list wishing we'd release more often. For example:* "Desperately waiting for an Aries release after loooong time.."* "The problem with Aries is they seem to be too busy coding to release anything."* "Compared to other projects (like Karaf and Camel) Aries releasestend to take quite some time."* "It's 2012 now and Aries 0.3 is almost a year old. Is there anychance of a new Aries JPA release any time soon? "* "Looks like Apache Aries has made no visible progress since Jan 2011, if the time stamps on the maven central artefacts are to bebelieved."------------------------------- Why what we have isn't working for us------------------------------- Both Dan and I are trying to do releases at the moment, andstrugglingto get enough PMC votes. Dan's release is to back port a show- stopper proxy fix, so a release there is particularly pressing - he's got a non-binding +infinity vote, but that's all. My test support release vote has been open for about 64 hours, and only got one vote so far (thanks David B!). Obviously testsupport is less exciting than proxy,but that bundle does block more interesting releases.Why aren't people voting? My guess is that it's too much work to dothe full set of verifications described athttp://aries.apache.org/development/verifyingrelease.html. There areseven steps, and while they don't actually take that long tocomplete,it's enough of a burden that we tend to leave the voting to someone else unless we really care about a release. I'm as guilty of this as anyone - I think a release is a good idea, but I'm spending enough time working on the 1.0.0 release that I don't want to take time out to vote on another release. I suspect Dan might feel exactly the sameabout my 1.0.0 bundles. :)With release-by-bundle, there's a lot of verifications. Excluding the sandbox code, we have 123 bundles to release in 1.0.0. At three votes per bundle, that means the PMC need to do 369 MD5 checks, 369 PGP checks, 369 RAT checks, and so on, just to get 1.0.0 out the door. This just doesn't seem like it scales. Batching the bundle releasestogether eases some of this burden, but not all. ------------------------------- What I propose -------------------------------I suggest we move to a more trust-based system, where PMC members carefully check releases if they want, but where in general they're voting on the principle of the release, rather than the mechanics of the archives. In particular, they don't feel compelled to do checksbefore voting. If PMC members could say "Our users need thisfunction,so +1", or "I know Holly has done sensible things in the past, so +1"or even "Do I want to check the SHAs on a test support bundle?Really?+1" it would get our releases moving better, and also save work forall of us.(At the moment I think what's happening is people are thinking "Do I want to check the SHAs on a test support bundle? Really?" and thenskipping the +1 bit. :) )To ensure that at least *someone* has run the checks, the release manager could include the output of the seven checks in an email to the list. I think this level of checking is perfectly compatible with the minimum Apache process, which is that the release manager signsthe artefacts and three PMC members vote +1 (http://www.apache.org/dev/release-publishing.html#voted). What do people think? Holly-- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com-- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com-- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com-- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
