aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: [DISCUSSION] Modifications to Aries release process
Date Mon, 25 Jun 2012 08:33:40 GMT
Well, it seems you're already using it ;-)

On Mon, Jun 25, 2012 at 10:30 AM, Guillaume Nodet <> wrote:
> Felix has a script to check the signatures if that can help to add
> more "automatic" testing
> 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
> <> 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
>> 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
>> (
>> What do people think?
>> Holly
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog:
> ------------------------
> FuseSource, Integration everywhere

Guillaume Nodet
FuseSource, Integration everywhere

View raw message