hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [VOTE] Release HttpComponents Client 4.4-alpha1 based on RC1
Date Sun, 29 Jun 2014 16:31:57 GMT
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? 

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.

> >> >> 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.
> 

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.

Oleg   



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


Mime
View raw message