aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: [DISCUSSION] Modifications to Aries release process
Date Mon, 25 Jun 2012 18:07:31 GMT

Honestly, with the change to using Nexus, the SHA1 and MD5 checks are 
completely pointless.   Nexus generates them itself based on what's 
uploaded.  The "is it a valid signature" part of the GPG testing is also 
pointless as Nexus won't let you close the repo unless the signatures are 
valid.   The only check you really need to do is to make sure the key that 
was used is "trusted" by you.   (aka: was it really Holly who deployed those 
artifacts)    So the monontonous parts of checking that stuff is really 
irrelevant at this point.  (providing we trust that infra has Nexus 
sufficiently locked down and secure)

I actually don't have a big issue with the difficulting in getting votes.  
I'm involved in another community that has a PMC that is easily 4 times the 
size of this one, yet we still have difficulting getting votes there.   
While not ideal, life events can cause priority shifts and such so people 
may not be able to be as responsive.

My bigger problem is that the entire per bundle release process and symantic 
versioning crap has put a HUGE burden on the release manager.   That makes 
it much harder to get quality releases out and makes it less likely that 
anyone will step up to get "minor fixes" released.   The only reason I 
stepped up with the 0.3.1 bp stuff is that *MY*  customers are being 
affected by it.   Like wise for the proxy stuff.   If *my* customers were 
not affected, I don't think I would have spent the time and effort.    If 
the process for getting fixes and releases out to users was smaller and 
easier, I have no problem doing them.   For CXF, we do full releases on 3 
branches every other month or so.   But that's because it's EASY to do. 

If it was up to me, I'd toss out the entire versioning thing with 1.0 and go 
back to per module versioning thing.   So my fix to proxy would  have 
involved checking out all of "proxy", fixing it, and releasing all of proxy 
as a proxy "0.3.1", even the modules that haven't changed.   It's just a 
huge hassle to track down which bundles have changed, which haven't which 
version numbers need to be updated, etc....   If it's not quick and easy to 
do releases as a release manager, very few people are going to step up to do 
it.     It may not be 100% "proper OSGi", but IMO, getting fixes and such to 
the users is more important than that.    But that's my opinion.


On Saturday, June 23, 2012 03:27:07 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
Daniel Kulp -
Talend Community Coder -

View raw message