Jeremy has pointed out that while I was looking at http://www.apache.org/dev/release-publishing.html#voted, which only says that a release needs three PMC +1s, http://www.apache.org/dev/release.html#approving-a-release has a stronger set of requirements on the voting PMC members:
"Before voting +1 PMC members are required to download the signed source code package, compile it as provided, and test the resulting executable on their own platform, along with also verifying that the package contains the required contents." So I think that rather nixes my idea for the lighter weight approval criteria, at least if we want to comply with the Apache process. However, there may still be hope of reducing the voting burden if we can automate nearly everything using Guillaume's script idea. We may even be able to automate something clever for integration testing, although it would require a bit more thought. Holly On Sat, Jun 23, 2012 at 3: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
