hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [VOTE] Release HttpComponents Client 4.4-alpha1 based on RC1
Date Sun, 29 Jun 2014 16:22:27 GMT
On 29 June 2014 17:07, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Sun, 2014-06-29 at 16:55 +0100, sebb wrote:
>> On 29 June 2014 15:59, Oleg Kalnichevski <olegk@apache.org> wrote:
>> > On Sun, 2014-06-29 at 15:27 +0100, sebb wrote:
>> >> On 29 June 2014 15:15, Oleg Kalnichevski <olegk@apache.org> wrote:
>> >
>
> ...
>
>> >> >
>> >> > What we release is a source tarball. Binary artifacts are distributed
>> >> > merely for convenience of users.
>> >>
>> >> Yes, they are optional.
>> >>
>> >
>> > Ah, finally. So are website or any reports.
>>
>> The website is not really optional as far as consumers are concerned,
>> but is not generally subject to a release vote.
>> However there are still some rules (e.g. branding) which the site must follow.
>>
>> The reports are not strictly needed for consumers, although the Clirr
>> one may be useful.
>> However, some of the are important for the purpose of the release vote.
>>
>
> So, they can be and should be built from source.

As I wrote previously, RAT and Clirr are important parts of the
release vote process.
So yes of course the reviewers can and should run the checks themselves.
This applies to the RM as well.

But I think it is important to document that these checks have been
done by providing the links in the release vote e-mail.

>> >> But they are still distributions, and still need to follow the rules
>> >> regarding NOTICE and LICENSE etc.
>> >> And sigs/hashes must be OK
>> >> ETC.
>> >>
>> >
>> > Yes, by making sure that the correct artifacts can be built from source.
>>
>> No (*).
>>
>> Assuming that the RM intends to publish the binary jars to Maven and
>> the binary bundle to the ASF mirrors, then these are distributions. As
>> such they must meet the requirements.
>>
>> For example the ASF does not allow bundling of 3rd party code that is
>> not compatible with the AL2.0. This is to ensure consumers can be sure
>> that the downloads we provide are available under the AL2.0 license.
>>
>> (*) ensuring that the artefacts can be built from source is a separate issue.
>>
>
> No.

Huh?

I see two separate (but related) issues here:

- do the binary artefacts that are provided as part of the release
vote meet the requirements?
- can I build the binary artefacts myself, and if so do they look
similar to the ones in the vote?

It's quite possible that my host system has a problem that prevents me
from building the code.
However that does not mean that any checks I do on the RC binaries are useless.

Of course, if there are build problems on my system, ideally these
need to be investigated in case there is a problem with the scripts
that only exhibits itself on certain host types. But that does not
necessarily mean that the RC fails.

> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message