I agree. I'd like to see releases be source first with binary versions provided in parallel where the RM chooses to provide them.
On alphas, I think what is important is that we ship alpha releases, so everyone has something to test and begin integration with. I'd encourage folks to +1 with some flaws, with the expectation that flaws will be fixed later. On names, Alphas should be clearly labeled on the site. That is critical. Beyond that I don't think it maters. --- E14 - typing on glass On Nov 1, 2011, at 4:36 PM, Doug Cutting <[email protected]> wrote: > On 11/01/2011 03:48 PM, Doug Cutting wrote: >> -1 This is not a release tarball that folks can vote on, since it >> contains no source code. Please cancel this vote and start a new vote >> on an actual source code tarball. > > Okay, I found source code in 8 embedded jars: > > % find hadoop-0.23.0 -name '*-sources.jar' > hadoop-0.23.0/hadoop-mapreduce-examples-0.23.0-sources.jar > hadoop-0.23.0/share/hadoop/common/hadoop-common-0.23.0-test-sources.jar > hadoop-0.23.0/share/hadoop/common/hadoop-common-0.23.0-sources.jar > hadoop-0.23.0/share/hadoop/hdfs/hadoop-hdfs-0.23.0-test-sources.jar > hadoop-0.23.0/share/hadoop/hdfs/hadoop-hdfs-0.23.0-sources.jar > hadoop-0.23.0/hadoop-mapreduce-test-0.23.0-sources.jar > hadoop-0.23.0/hadoop-mapreduce-tools-0.23.0-sources.jar > hadoop-0.23.0/hadoop-mapreduce-0.23.0-sources.jar > > It's awkward at best to build and run tools like RAT on such a release. > I'd much prefer a tarball that directly includes a buildable > source-file tree, more-or-less an 'svn export' to vote on. Folks should > not primarily evaluate binaries when voting. The ASF primarily produces > and publishes source-code so voting artifacts should be optimized for > evaluation of that. End-user artifacts should be generated by the > source code. > > Doug
