Hi Guillaume, As it happens, I wasn't already using it. :) I'd just followed the instructions on Jeremy's web page. A shareable script sounds like a great idea, though, so I'm glad you've mentioned it. I'll have a look at the Felix one and adapt it to Aries, and then link to it from the vote threads and the release page. Hopefully that will make voting on releases easier.
On Mon, Jun 25, 2012 at 9:33 AM, Guillaume Nodet <[email protected]> wrote: > Well, it seems you're already using it ;-) > > On Mon, Jun 25, 2012 at 10:30 AM, Guillaume Nodet <[email protected]> wrote: >> Felix has a script to check the signatures if that can help to add >> more "automatic" testing >> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh >> which we could easily adapt for aries. >> >> For Dan's vote, the vote is only up for 3 days, including the >> week-end, so that does not really abnormal to me. >> >> On Sat, Jun 23, 2012 at 4:27 PM, Holly Cummins >> <[email protected]> wrote: >>> Hi all, >>> >>> Now that Jeremy's taken the time to write up our release verification >>> process, I'd like to propose we change it. :) I think it's too onerous >>> on the pmc, which therefore also inhibits our ability to be responsive >>> to our users. >>> >>> >>> ------------------------------- Why what we have isn't working for the >>> community ------------------------------- >>> >>> 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 releases >>> tend to take quite some time." >>> * "It's 2012 now and Aries 0.3 is almost a year old. Is there any >>> chance 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 be >>> believed." >>> >>> ------------------------------- Why what we have isn't working for us >>> ------------------------------- >>> >>> Both Dan and I are trying to do releases at the moment, and struggling >>> to 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 do >>> the full set of verifications described at >>> http://aries.apache.org/development/verifyingrelease.html. There are >>> seven steps, and while they don't actually take that long to complete, >>> 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 same >>> about 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 releases >>> together 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 checks >>> before voting. If PMC members could say "Our users need this function, >>> 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 for >>> all 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 then >>> skipping 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 signs >>> the artefacts and three PMC members vote +1 >>> (http://www.apache.org/dev/release-publishing.html#voted). >>> >>> What do people think? >>> >>> Holly >> >> >> >> -- >> ------------------------ >> 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
