On 11/02/2012 07:06 PM, Jasha Joachimsthal wrote:
On 1 November 2012 23:50, Ate Douma <[email protected]> wrote:
Discussion thread for vote on 0.17 release candidate.
For more information on the release process, checkout -
http://www.apache.org/dev/**release.html<http://www.apache.org/dev/release.html>
Some of the things to check before voting are:
- can you run the demo binaries
yes
- can you build the contents of source-release.zip and svn tag
yes
- do all of the staged jars/zips contain the required LICENSE and NOTICE
files
yes
- are all of the staged artifacts signed and the signature verifiable
rave-portal-0.17.war contains a jar that is not the one from Maven Central.
wookie-java-connector-0.10.0-incubating.jar was built by you, probably to
test its release.
Ah, good catch :)
Apparently I made a similar mistake with Rave 0.16.
shindig-common-2.5.0-beta3.jar in Rave 0.17 is from Maven central, the one
in Rave 0.16 was built by me. I thought I had built 0.16 against an empty
local repository, but apparently not. It also happened with the
wookie-java-connector in Rave 0.15 built by Matt.
Right, its an easy to overlook thing.
I agree this isn't 'proper', but I don't think it is a big deal either.
Note that this concerns 'non-source' artifacts which we build and bundle as
convenience for the community. These are *not* the release itself, which only is
the sources tarball.
While I didn't intend to have my locally build version of wookie bundled up, it
doesn't make much difference if you compare that with other 3rd party artifacts
we bundle up likewise. Including many non-Apache 3rd party artifacts which were
also build and released outside 'our' (Apache) release process.
Who is verifying those other 3rd party artifacts contents and by whom they were
build? Having as much as possible of these 3rd party artifacts coming from an
official and *verifiable* Apache release definitely helps, and therefore
bundling a locally (re)build of the wookie jar is less ideal. But as we still
have, and probably always will have, many other 3rd party artifacts bundled up
as well, it doesn't make much difference in the *assurance* level of these
binaries.
With regards to this specific wookie jar: you'll have to trust me I didn't
'hack' it to inject some nasty virus or likewise. Neither did I do such thing
while building the rave sources ... To be sure though you would have to
decompile both this wookie jar *and* all the rave jars as well, and try to
verify them that way. Which should make clear that isn't the point.
What remains therefore, and what *is* important for the community, is that what
we provide (as convenience) and release (as source) is properly signed and thus
verifiable the same artifacts we voted upon.
And this is why we say only the voted upon and signed *sources* constitute the
release. Binaries are just provided for convenience and remains the
responsibility of the end-user to verify and trust, or else better build
themselves.
Actually in Java/Maven land we have it quite easy: compare this with providing
native builds, which might *require* the Release Manager to build many 3rd party
sources locally first...
In short: I don't think this really matter much, certainly not enough to cancel
or redo a release for. Not would it be if it happens again in the future.
But also: the more we use verifiable Apache or other 3rd party artifacts, the
easier it is to verify and trust it, so we should strive for not making such
accidental mistakes.
Thanks, Ate
- is the signing key in the project's KEYS file and on a public server
yes
