Wow; thanks for taking this to ground, Matt. I don't think we need to rerun the vote. While you've paged it in, would you mind adding some of this context to the HowToRelease wiki? -C
On Mon, May 13, 2013 at 5:35 PM, Matt Foley <mfo...@hortonworks.com> wrote: > 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 > http://incubator.apache.org/guides/releasemanagement.html#best-practicewhich > 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? > > Thanks, > --Matt > > > > On Mon, May 13, 2013 at 4:32 PM, Chris Douglas <cdoug...@apache.org> 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 <mfo...@hortonworks.com> >> 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. >> > >> > Furthermore, I believe the Hadoop-related projects make use of a Maven >> > server. I don't believe it's distributing source only :-) >> > >> > I totally agree that the official release is the sources. But to go from >> > there to a prohibition on distributing objects would, I think, cripple >> the >> > project, and certainly goes against the tradition of common usage in >> > opensource projects, including many Apache projects. >> > >> > Respectfully, >> > --Matt >> > >> > >> > >> > On Mon, May 13, 2013 at 2:01 PM, Chris Douglas <cdoug...@apache.org> >> wrote: >> > >> >> Thanks, Matt. As always, your work on this is hugely appreciated. >> >> >> >> As I understand it, we can't distribute binary-only artifacts. Among >> >> the reasons: the PMC can't verify binaries as project output, the >> >> non-profit charter is about source code, and users need to be able to >> >> modify what we distribute. I can try to track down a reference, but >> >> I'm pretty sure on this one... source-only is OK. Some have argued >> >> it's the only acceptable form. -C >> >> >> >> On Mon, May 13, 2013 at 1:36 PM, Matt Foley <ma...@apache.org> wrote: >> >> > The vote passed and we have accepted Hadoop version 1.2.0 for release: >> >> > +1 binding: 4 (1 slightly late) >> >> > +1 non-binding: 1 >> >> > 0 none >> >> > -1 none >> >> > >> >> > Thanks to all who voted. >> >> > I'll finish publishing the release tonight and announce it to >> general@in >> >> > the morning. >> >> > >> >> > Best regards, >> >> > --Matt >> >> > release manager >> >> > >> >> > >> >> > On Mon, May 13, 2013 at 1:32 PM, Matt Foley <mfo...@hortonworks.com> >> >> wrote: >> >> > >> >> >> Hi Chris, >> >> >> Unless I screwed up my build, hadoop-1.2.0.tar.gz includes the built >> >> >> artifacts as well as full buildable source and docs. >> >> >> Hadoop-1.2.0-bin.tar.gz is intended to contain only the built >> artifacts >> >> >> ("binaries") and deliberately excludes the source >> >> >> and docs, for those who wish a smaller tarball of binaries only. The >> >> >> artifacts in both are from the same build. >> >> >> >> >> >> So I'll take your +1 on the source tarball :-) >> >> >> Thanks, >> >> >> --Matt >> >> >> >> >> >> >> >> >> On Mon, May 13, 2013 at 1:13 PM, Chris Douglas <cdoug...@apache.org >> >> >wrote: >> >> >> >> >> >>> +1 on hadoop-1.2.0.tar.gz (verified checksums, signature, ran some >> unit >> >> >>> tests) >> >> >>> >> >> >>> but hadoop-1.2.0-bin.tar.gz is missing the source code and can't be >> >> >>> built. -C >> >> >>> >> >> >>> On Mon, May 6, 2013 at 11:11 AM, Matt Foley <ma...@apache.org> >> wrote: >> >> >>> > Hi all, >> >> >>> > I have posted the signed tarballs for Hadoop 1.2.0-rc1 at >> >> >>> > http://people.apache.org/~mattf/hadoop-1.2.0-rc1/ >> >> >>> > Release notes are at: >> >> >>> > releasenotes_1.2.0-rc1.html< >> >> >>> >> >> >> http://people.apache.org/~mattf/hadoop-1.2.0-rc1/releasenotes_1.2.0-rc1.html >> >> >>> > >> >> >>> > >> >> >>> > I'm having a little trouble with Nexus (it seems to have >> forgotten I >> >> >>> exist) >> >> >>> > but am working on that and will post to Nexus as soon as possible. >> >> >>> > >> >> >>> > In the meantime, unless there are objections, I'd like to start >> the >> >> >>> vote. >> >> >>> > Please review this release candidate and vote it for release. >> Vote >> >> >>> will end >> >> >>> > in seven days as usual, at 11:30am PDT on Monday 13 May. >> >> >>> > >> >> >>> > Best regards, >> >> >>> > --Matt >> >> >>> > (release manager) >> >> >>> >> >> >> >> >> >> >> >> >>
