Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Hadoop >> mail # dev >> [VOTE] Hadoop release candidate 1.2.0-rc1


+
Matt Foley 2013-05-06, 18:11
+
Matt Foley 2013-05-06, 18:36
+
Matt Foley 2013-05-10, 16:44
+
Jason Lowe 2013-05-11, 01:35
+
Matt Foley 2013-05-11, 19:02
+
Jason Lowe 2013-05-13, 01:23
+
Chris Nauroth 2013-05-13, 03:27
+
Suresh Srinivas 2013-05-10, 21:45
+
Chris Douglas 2013-05-13, 20:13
+
Matt Foley 2013-05-13, 20:32
+
Matt Foley 2013-05-13, 20:36
+
Chris Douglas 2013-05-13, 21:01
+
Matt Foley 2013-05-13, 21:44
+
Chris Douglas 2013-05-13, 23:32
+
Matt Foley 2013-05-14, 00:35
+
Chris Douglas 2013-05-14, 02:14
Copy link to this message
-
Re: [VOTE] Hadoop release candidate 1.2.0-rc1
Sure, will do. --M
On Mon, May 13, 2013 at 7:14 PM, Chris Douglas <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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 <[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"
+
Arun C Murthy 2013-05-13, 05:29
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB