aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <>
Subject Re: [DISCUSSION] Modifications to Aries release process
Date Tue, 26 Jun 2012 08:06:47 GMT

I have to second Dan here.
As a user it's a PITA to keep track of 3 different versions for all
the required Blueprint artifacts.
Just to give you a simple example using Blueprint (0.3.2) with Proxy
(0.3.1) and JPA (0.3)
and Transaction (0.3 and 0.3.1). Especially to find the right version
for the same "kind" of bundles
is not a intuitive way of doing. I'd rather prefer all bundles of the
same type to have the same version.

Regards, Achim

2012/6/25 Daniel Kulp <>:
> 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 -


Apache Karaf <> Committer & PMC
OPS4J Pax Web <>
Committer & Project Lead
OPS4J Pax for Vaadin
<> Commiter & Project
blog <>

View raw message