On 3 November 2012 10:13, Ate Douma <[email protected]> wrote: > 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> >>> <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. >
In the manifest of the Shindig common jar I accidentally included from my local repository in 0.16 it says I had built it with Java 7. This could be an inconvenience for Java 6 users if the build plugin didn't target for Java 6, but until now nobody has complained. > > 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. > Okay in that case I'm okay with this release. If you're really customising a Rave setup, it's better to build your own war instead of overlaying the one we provide > > 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. > Oof I almost thought you did something evil ;) > 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. > It's not a reason for a < 0 vote for me either, especially if the source tarball is the only artifact that really mattrs. Just another wakeup call that the Maven build process is not 100% reliable. > > Thanks, Ate > > > >> - is the signing key in the project's KEYS file and on a public server >> >>> >>> yes >> >> >
