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: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer;
  b=YAEa8crMb6I457BPF6NiwQbEeNO+wONSEDjEnMJP6J5sy9sGiPCH+RyJbSbFIRWi+NFE3XDNytQ6BP2lXdcd6iycPaYSYJ1bMToVYm2AJ9czEQfW6DRtnBnPnpCsUzji22frvt7BVrmnB9VQcTiBvAza6q3R0dInWWSvjWgdNsg=
  ;
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: [DISCUSSION] Modifications to Aries release process
From: David Jencks <david_jencks@yahoo.com>
In-Reply-To: <2956591.HBzuJNjzLo@dilbert.dankulp.com>
Date: Mon, 25 Jun 2012 15:20:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <C0CF6481-EA0E-42E4-BF79-93BEB23A0974@yahoo.com>
References: 
 <CAC9tjn90Nh3oWAzrgMindNYTQzpWvDPud008T2QRXyCT4YchKQ@mail.gmail.com>
 <2956591.HBzuJNjzLo@dilbert.dankulp.com>
To: dev@aries.apache.org

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 :-)

thanks
david jencks

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

>=20
> Honestly, with the change to using Nexus, the SHA1 and MD5 checks are=20=

> completely pointless.   Nexus generates them itself based on what's=20
> uploaded.  The "is it a valid signature" part of the GPG testing is =
also=20
> pointless as Nexus won't let you close the repo unless the signatures =
are=20
> valid.   The only check you really need to do is to make sure the key =
that=20
> was used is "trusted" by you.   (aka: was it really Holly who deployed =
those=20
> artifacts)    So the monontonous parts of checking that stuff is =
really=20
> irrelevant at this point.  (providing we trust that infra has Nexus=20
> sufficiently locked down and secure)
>=20
>=20
> I actually don't have a big issue with the difficulting in getting =
votes. =20
> I'm involved in another community that has a PMC that is easily 4 =
times the=20
> size of this one, yet we still have difficulting getting votes there.  =
=20
> While not ideal, life events can cause priority shifts and such so =
people=20
> may not be able to be as responsive.
>=20
> My bigger problem is that the entire per bundle release process and =
symantic=20
> versioning crap has put a HUGE burden on the release manager.   That =
makes=20
> it much harder to get quality releases out and makes it less likely =
that=20
> anyone will step up to get "minor fixes" released.   The only reason I=20=

> stepped up with the 0.3.1 bp stuff is that *MY*  customers are being=20=

> affected by it.   Like wise for the proxy stuff.   If *my* customers =
were=20
> not affected, I don't think I would have spent the time and effort.    =
If=20
> the process for getting fixes and releases out to users was smaller =
and=20
> easier, I have no problem doing them.   For CXF, we do full releases =
on 3=20
> branches every other month or so.   But that's because it's EASY to =
do.=20
>=20
> If it was up to me, I'd toss out the entire versioning thing with 1.0 =
and go=20
> back to per module versioning thing.   So my fix to proxy would  have=20=

> involved checking out all of "proxy", fixing it, and releasing all of =
proxy=20
> as a proxy "0.3.1", even the modules that haven't changed.   It's just =
a=20
> huge hassle to track down which bundles have changed, which haven't =
which=20
> version numbers need to be updated, etc....   If it's not quick and =
easy to=20
> do releases as a release manager, very few people are going to step up =
to do=20
> it.     It may not be 100% "proper OSGi", but IMO, getting fixes and =
such to=20
> the users is more important than that.    But that's my opinion.
>=20
>=20
> Dan
>=20
>=20
>=20
> On Saturday, June 23, 2012 03:27:07 PM Holly Cummins wrote:
>> Hi all,
>>=20
>> 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.
>>=20
>>=20
>> ------------------------------- Why what we have isn't working for =
the
>> community -------------------------------
>>=20
>> 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:
>>=20
>> * "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."
>>=20
>> ------------------------------- Why what we have isn't working for us
>> -------------------------------
>>=20
>> 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.
>>=20
>> 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. :)
>>=20
>> 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.
>>=20
>> ------------------------------- What I propose
>> -------------------------------
>>=20
>> 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.
>>=20
>> (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. :)  )
>>=20
>> 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).
>>=20
>> What do people think?
>>=20
>> Holly
> --=20
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com