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 14:15:54 GMT
On Sun, 2014-06-29 at 15:04 +0100, sebb wrote:
> On 29 June 2014 14:42, Oleg Kalnichevski <olegk@apache.org> wrote:
> > On Sun, 2014-06-29 at 14:24 +0100, sebb wrote:
> >> On 29 June 2014 12:55, Oleg Kalnichevski <olegk@apache.org> wrote:
> >> > On Sun, 2014-06-29 at 01:14 +0100, sebb wrote:
> >> >> On 28 June 2014 09:28, Oleg Kalnichevski <olegk@apache.org> wrote:
> >> >> > On Sat, 2014-06-28 at 00:24 +0100, sebb wrote:
> >> >> >> On 27 June 2014 20:44, Oleg Kalnichevski <olegk@apache.org>
wrote:
> >> >> >> > On Fri, 2014-06-27 at 17:56 +0100, sebb wrote:
> >> >> >> >> I'm inclined to agree with Gary that the site is
important as a help
> >> >> >> >> when reviewing the RC.
> >> >> >> >>
> >> >> >> >> Apart from the RAT report, there is the Clirr report.
> >> >> >> >>
> >> >> >> >
> >> >> >> > What's wrong with 'mvn clirr:check', which is a part
of the release
> >> >> >> > process anyway? One is welcome to add RAT maven plugin
as well.
> >> >> >>
> >> >> >> My point is that these reports should be part of the RC VOTE.
> >> >> >>
> >> >> >
> >> >> > Right, and 'mvn clirr:check' gives you exactly that report. Voting
on
> >> >> > some pre-generated report or website is _idiocy_ because there
is no way
> >> >> > of telling if those reports actually match the release artifacts
voted
> >> >> > upon.
> >> >>
> >> >> There's also no way to be sure that the binaries agree with the source.
> >> >
> >> > And here we go. Voting on binary artifacts is equally stupid. The only
> >>
> >> Sorry, that was a bad analogy.
> >>
> >> But there are some aspects of binary artifacts that can - and should -
> >> be checked.
> >>
> >> For example, sigs, hashes, NOTICE and LICENSE.
> >> Ensuring that the binary artifacts don't contain bundled items that
> >> should not be present.
> >> Ensuring that jars have suitable MANIFEST entries
> >>
> >
> > Which one should do by generating those binary artifacts from the
> > source.
> 
> Huh?
> How does that help?
> 
> The binary artifacts in the release vote are the ones that are going
> to be published via the ASF mirrors.
> So they are the ones that need checking to ensure that nothing has
> gone wrong with the build.
> 
> Any build others may do is not directly relevant to the artifacts that
> are proposed for release.
> 

What we release is a source tarball. Binary artifacts are distributed
merely for convenience of users.

Oleg



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


Mime
View raw message