aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holly Cummins <>
Subject [DISCUSSION] Modifications to Aries release process
Date Sat, 23 Jun 2012 14:27:07 GMT
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

------------------------------- 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?


View raw message