aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [DISCUSSION] Modifications to Aries release process
Date Mon, 25 Jun 2012 19:20:22 GMT
Hi Dan,

At the moment, its certainly true that the aries release process is really hard.  On the other
hand, we haven't really gotten a baseline yet against which we can release fixes.  I'd rather
not throw away semantic versioning and per-bundle releases until after we have a baseline
release and find out that its still really hard to release a small fix.  (Hopefully this will
be before we kill Holly with all the work she's doing :-)

Another thing that may be producing conceptual friction here is that aries is using maven
and many of the consumers of aries are well aware of the enormous impedance gap between maven
and osgi and are not in favor of weakening osgi principles which are entirely positive in
non-maven environments for the convenience of a maven build.

I really appreciate you pointing out all the stuff about signatures and hashes.  Generally
when I vote I basically check that the source artifact builds and produces something that
is similar to the binary artifacts in the vote and, when possible, works in some environment
I have.  I'm glad to know my ignoring the hashes and sigs has not been all that serious :-)

david jencks

On Jun 25, 2012, at 2:07 PM, Daniel Kulp wrote:

> 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.
> Dan
> 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