Sure, will do. --M
On Mon, May 13, 2013 at 7:14 PM, Chris Douglas <cdoug...@apache.org> wrote: > 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) > >> >> >>> > >> >> >> > >> >> >> > >> >> > >> >
