Hi Holly, I'm very much in favour of doing frequent releases without too many obstacles. While I would hope that the release quality is generally very good, I always think that if doing them is relatively easy that if a release turns out to be bad that we can always do another release afterwards to fix the issue.
I think that it would be up to the voter to decide why to vote. Some pmc members might do a very thorough investigation before casting their vote, others might not. In any case there is value in both IMHO. So, +1 to your proposal from me. Cheers, David On 23 June 2012 15:27, 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
