[DISCUSS] Apache Rave 0.17 Release Candidate

[Ate Douma <at...@douma.nu>]

Discussion thread for vote on 0.17 release candidate.

For more information on the release process, checkout -
http://www.apache.org/dev/release.html

Some of the things to check before voting are:
- can you run the demo binaries
- can you build the contents of source-release.zip and svn tag
- do all of the staged jars/zips contain the required LICENSE and NOTICE files
- are all of the staged artifacts signed and the signature verifiable
- is the signing key in the project's KEYS file and on a public server

Re: [DISCUSS] Apache Rave 0.17 Release Candidate

[Jasha Joachimsthal <ja...@apache.org>]

On 3 November 2012 10:13, Ate Douma <at...@douma.nu> wrote:

> On 11/02/2012 07:06 PM, Jasha Joachimsthal wrote:
>
>> On 1 November 2012 23:50, Ate Douma <at...@douma.nu> 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
>>
>>
>

Re: [DISCUSS] Apache Rave 0.17 Release Candidate

[Ate Douma <at...@douma.nu>]

On 11/02/2012 07:06 PM, Jasha Joachimsthal wrote:
> On 1 November 2012 23:50, Ate Douma <at...@douma.nu> 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
>

Re: [DISCUSS] Apache Rave 0.17 Release Candidate

[Jasha Joachimsthal <ja...@apache.org>]

On 1 November 2012 23:50, Ate Douma <at...@douma.nu> 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.

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.

- is the signing key in the project's KEYS file and on a public server
>
yes