Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # dev - [VOTE] Hadoop release candidate 1.2.0-rc1

Copy link to this message
Re: [VOTE] Hadoop release candidate 1.2.0-rc1
Matt Foley 2013-05-14, 00:35
Thanks for the reference.

Roy's email clearly says that the thing to be voted on should be source
only. This email is in the context of a discussion about a release
candidate that incorporated jars (from a third-party project) WITHOUT
sources.  In particular, the offending project had apparently captured
certain object files that were depended upon, and included them in the
"source" repository.  This is not what Hadoop builds do.

The document http://www.apache.org/dev/release.html which is stated to be
normative, says,

All releases are in the form of the source materials needed to make changes
to the software being released. In some cases, binary/bytecode packages are
also produced as a convenience to users that might not have the appropriate
tools to build a compiled version of the source. In all such cases, the
binary/bytecode package must have the same version number as the source
release and may only add binary/bytecode files that are the result of
compiling that version of the source code release.
And the document
is referenced multiple times in Roy's email (although it states
itself to be non-normative), obviously contemplates that binaries may be
released along with the sources, because in the section about the "release
artifacts distribution directory" it says,

Many projects [optionally] use structured layouts... The common theme is
that each type of artifact is grouped into a subdirectory. For example,
binary packages into binaries and source packages into source (say).
So it is very clear that we may continue producing convenience binary
artifacts, as long as they are a result of and of identical provenance as
the sources.
And I hope we all understand that the file hadoop-1.2.0-bin.tar.gz met that
criteria, and was only for convenience and was not the subject of the vote.

However, the file hadoop-1.2.0.tar.gz, which was the subject of the vote,
included both source (full, buildable source), and a corresponding set of
built artifacts produced from that source on a CentOS 6 platform under my
control per (in the normative document)
http://www.apache.org/dev/release.html#owned-controlled-hardware .  Once
again, it was the intent that only the sources were the subject of the
vote, and the binaries themselves are clearly of the kind anticipated by
these policies.

BUT if the fact of packaging them together invalidated the vote, I will
re-create it and run a vote again.

Regardless, I will going forward change the build.xml file to produce a
pure source tarball so that can be the unambiguous subject of the vote.

Roy, if you're listening in, can you please say whether I need to re-do
this vote?


On Mon, May 13, 2013 at 4:32 PM, Chris Douglas <[EMAIL PROTECTED]> wrote:

> FWIW: http://s.apache.org/nnN
> The rest of the thread (and related discussion that month) is fairly
> unambiguous about what the PMC is allowed to approve. Elsewhere,
> there's clarification that the prohibition is against binaries for
> which we don't also distribute source, so (AFAICT) distributing
> third-party jars is also not kosher. I'll ask for clarification. -C
> On Mon, May 13, 2013 at 2:44 PM, Matt Foley <[EMAIL PROTECTED]>
> wrote:
> > Hmm.  My understanding was that only sources constituted a "release" and
> > that all release votes were to be understood as votes on a body of source
> > code. However, we've always (at least for the last 2+ years that I've
> been
> > involved in the RM side) distributed binary tarball (and often rpms and
> > debs), ALONG WITH the source tarball, for the convenience of our many
> users
> > who don't care to do builds before using a release.  The binaries and
> > source-containing artifacts are all signed for tamper-resistance, and
> when
> > a Release Manager distributes a set of stuff, the binaries should be
> > understood to come from the same build as the source tarball -- as is
> > indeed the case here.