Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 209.85.212.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1404053964.15474.1.camel@ubuntu>
References: <1403714005.10592.1.camel@ubuntu>
	<1403855847.23981.0.camel@ubuntu>
	<CACZkXPy7-WwL+pG7zhmTYLMXg5HfS0hthX3_hFB+7qF-cmBV6g@mail.gmail.com>
	<1403872248.576.1.camel@ubuntu>
	<CACZkXPz0hrFZNZ_cr9CbKibEZKx450SO+tA1xNL425wqFY9NUg@mail.gmail.com>
	<CACZkXPyo30saBPw2EHbU5fyiwPuWefXkh6idNbJ9sCGn-eBDZw@mail.gmail.com>
	<1403880423.5473.3.camel@ubuntu>
	<CACZkXPxmqMo7VtZLV7um_F-4a9AK02ZV5DV8VyJcby9r4ciy5A@mail.gmail.com>
	<1403881529.5473.11.camel@ubuntu>
	<CACZkXPzjCtFsWozz6WUMnR3CfeXpvNxkAfqNXOJpe9jhnv6PVA@mail.gmail.com>
	<1403886338.7430.13.camel@ubuntu>
	<CAOGo0VYbAfFxX3GhL0eG-y7sYSDaQn5nzb6HzeHYWeFoHHAuSg@mail.gmail.com>
	<1403898245.12543.6.camel@ubuntu>
	<CAOGo0VYCxHF+Urz+PufK4oObgVJ6zyrSC3Grea074mdrgWAfdw@mail.gmail.com>
	<1403944094.16520.4.camel@ubuntu>
	<CAOGo0VZtEeC_8VPPYVSMZo=4z98O-=yQj6o2+5TrJfqKYEWb4A@mail.gmail.com>
	<1404042902.6021.5.camel@ubuntu>
	<CAOGo0Va_dEAnS-2-1Jn4iYJpgXNam_h4MTLyD8nUF+hS5CFR9A@mail.gmail.com>
	<1404049325.12487.3.camel@ubuntu>
	<CAOGo0VYHbrYGJ3pzdZff6zsev8qLmNKZku7xDgVWWev=P4e9hg@mail.gmail.com>
	<1404051354.13648.2.camel@ubuntu>
	<CAOGo0VY7X-QPd3QSAWhLqUJKxOx8vQ_J9D5nH2XV54MTThMa8A@mail.gmail.com>
	<1404053964.15474.1.camel@ubuntu>
Date: Sun, 29 Jun 2014 16:55:36 +0100
Message-ID: 
 <CAOGo0VacVYXB=_UygEiKx7B-J=oJ+o_mwESBodi-88aLu1VATQ@mail.gmail.com>
Subject: Re: [VOTE] Release HttpComponents Client 4.4-alpha1 based on RC1
From: sebb <sebbaz@gmail.com>
To: HttpComponents Project <dev@hc.apache.org>
Content-Type: text/plain; charset=UTF-8

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

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

> 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