Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
Received-SPF: pass (nike.apache.org: domain of gnodet@gmail.com designates
 209.85.160.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <2956591.HBzuJNjzLo@dilbert.dankulp.com>
References: 
 <CAC9tjn90Nh3oWAzrgMindNYTQzpWvDPud008T2QRXyCT4YchKQ@mail.gmail.com>
	<2956591.HBzuJNjzLo@dilbert.dankulp.com>
Date: Thu, 28 Jun 2012 16:19:52 +0200
Message-ID: 
 <CAEQV+EGDNabghBmgVzKqZHm1-_ELMhvoFbWSj8CkbhMMk3Svwg@mail.gmail.com>
Subject: Re: [DISCUSSION] Modifications to Aries release process
From: Guillaume Nodet <gnodet@gmail.com>
To: dev@aries.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think one problem, considering the current votes, is that it's
really difficult to test anything.   Releasing api bundles with no
implementation to test is definitely not helping imo.
Holly, just a question: is there a specific reason why are you doing
the release in multiple votes ? It would be simpler to just release
everything in one go and wait for a longer time because there are more
things to check, or at least, release the api + implementation so that
we can actually try something.  Just my 2 cents.

On Mon, Jun 25, 2012 at 8:07 PM, Daniel Kulp <dkulp@apache.org> wrote:
>
> Honestly, with the change to using Nexus, the SHA1 and MD5 checks are
> completely pointless. =A0 Nexus generates them itself based on what's
> uploaded. =A0The "is it a valid signature" part of the GPG testing is als=
o
> pointless as Nexus won't let you close the repo unless the signatures are
> valid. =A0 The only check you really need to do is to make sure the key t=
hat
> was used is "trusted" by you. =A0 (aka: was it really Holly who deployed =
those
> artifacts) =A0 =A0So the monontonous parts of checking that stuff is real=
ly
> irrelevant at this point. =A0(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 t=
he
> 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 syman=
tic
> versioning crap has put a HUGE burden on the release manager. =A0 That ma=
kes
> it much harder to get quality releases out and makes it less likely that
> anyone will step up to get "minor fixes" released. =A0 The only reason I
> stepped up with the 0.3.1 bp stuff is that *MY* =A0customers are being
> affected by it. =A0 Like wise for the proxy stuff. =A0 If *my* customers =
were
> not affected, I don't think I would have spent the time and effort. =A0 =
=A0If
> the process for getting fixes and releases out to users was smaller and
> easier, I have no problem doing them. =A0 For CXF, we do full releases on=
 3
> branches every other month or so. =A0 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. =A0 So my fix to proxy would =A0have
> involved checking out all of "proxy", fixing it, and releasing all of pro=
xy
> as a proxy "0.3.1", even the modules that haven't changed. =A0 It's just =
a
> huge hassle to track down which bundles have changed, which haven't which
> version numbers need to be updated, etc.... =A0 If it's not quick and eas=
y to
> do releases as a release manager, very few people are going to step up to=
 do
> it. =A0 =A0 It may not be 100% "proper OSGi", but IMO, getting fixes and =
such to
> the users is more important than that. =A0 =A0But 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
>> http://aries.apache.org/development/verifyingrelease.html. 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. :) =A0)
>>
>> 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
>> (http://www.apache.org/dev/release-publishing.html#voted).
>>
>> What do people think?
>>
>> Holly
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com


--=20
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com