Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <1404053964.15474.1.camel@ubuntu>
Subject: Re: [VOTE] Release HttpComponents Client 4.4-alpha1 based on RC1
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpComponents Project <dev@hc.apache.org>
Date: Sun, 29 Jun 2014 16:59:24 +0200
In-Reply-To: 
 <CAOGo0VY7X-QPd3QSAWhLqUJKxOx8vQ_J9D5nH2XV54MTThMa8A@mail.gmail.com>
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>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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.

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

Oleg


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