aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Edstrom <>
Subject Re: [DISCUSSION] Modifications to Aries release process
Date Mon, 25 Jun 2012 23:17:55 GMT
I'm the +infinity vote :)
I think that what you are suggesting would be a great thing.
Keep up the good work!

On Jun 25, 2012, at 3:47 PM, Holly Cummins wrote:

> 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 <> wrote:
>> 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
>> ------------------------
>> Blog:
>> ------------------------
>> FuseSource, Integration everywhere

View raw message