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 18:07:54 GMT
On 29 June 2014 17:31, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Sun, 2014-06-29 at 17:22 +0100, sebb wrote:
>> On 29 June 2014 17:07, Oleg Kalnichevski <olegk@apache.org> wrote:
> ...
>> >> > 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.
> Links to what?

The reports.

> As I said previously it is irrelevant what kind of reports are published
> by RM as there is no reliable way that they match the source.

I already wrote, the reviewers can still run their own checks, as the RM must.
Including the reports in the RC VOTE shows that these items have been

If the reviewer's copies of the reports don't agree with the linked
ones then that can be investigated.
Clirr reports in particular are open to some interpretation, so it is
important that the reviewers know what RM based any decisions on.

>> >> >> But they are still distributions, and still need to follow the
>> >> >> 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.
> And I do not see two issues here. I see one and only issue here which
> whether or not the source tarball being voted upon can be used to build
> binary artifacts meeting specific requirements. Binary artifacts built
> by RM are merely convenience.

Yes, they are merely convenience, but as I already wrote, they are
distributions of software by the ASF.
And so are subject to rules on content and NOTICE and LICENSE etc.

It is important that the binaries are subject to at least some scrutiny.
For example, suppose a product depends on an LGPL dependency (this is
allowed under some circumstances.)
However, the dependency must not be bundled with the binaries.
So it is important that the reviewers are able to check the contents
of the RC binaries.

It does not really help if the reviewers check their own binaries, as
those are not the ones that are going to be distributed.
One might as well say that the reviewers should build their own source
bundle and vote on that, rather than voting on the artifacts that are
detailed in the RC vote.

> 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

View raw message