+1 on the latest artifacts. Downloaded and verified md5 and signature.
2011/12/5 Scott Carey <sc...@richrelevance.com>: > > > On 12/5/11 6:37 PM, "Konstantin Shvachko" <shv.had...@gmail.com> wrote: > >>Scott, >> >>I did not find anything in Apache policies about invalidating prior >>+1's in case of changing the bits. > > I am assuming that the votes prior to the change are invalidated as a > conclusion from what I understand to be an Apache release. The release > vote is about the legal aspect of the release artifacts. Are all the > contents are properly licensed and the package properly cryptographically > signed? Therefore, if the contents and signatures change even in the most > trivial way, then votes prior to the signature change cannot be taken to > be votes on the release at all. > http://www.apache.org/dev/release-publishing.html#signed > > I have no concern if you get 3 PMC +1's after the change and a majority of > PMC +1's ('lazy majority'). > > >>This change was intended for those who want to build their own >>binaries from the released source code. As I mentioned before there >>was no change to the source tree. > > It is a requirement that an Apache release be buildable from source, not > just contain source. > http://www.apache.org/dev/release-publishing.html#valid > >>To accommodate your concern, I'd like to reiterate that there was a >>trivial change in the directory structure of the release artifact. And >>people who voted before Dec 3, 2011 5:45 PM PST should revoke their >>votes if they think this change invalidated their +1's. > > I understand the change is trivial. > I am only concerned if the release fails to get 3 PMC +1's after the > change. Then I'd be a little uncertain of the official status of the vote > (did at least 3 PMC members verify the signatures?). The PMC's duty in a > release is to validate that the files released have valid contents _and_ > match their crypto signatures. > >> >>Thanks, >>--Konstantin >> >> >>2011/12/5 Scott Carey <sc...@richrelevance.com>: >>> >>> >>> On 12/3/11 10:52 PM, "Konstantin Boudnik" <c...@apache.org> wrote: >>> >>>>On Sat, Dec 03, 2011 at 04:40PM, Konstantin Shvachko wrote: >>>>> Roman, >>>>> >>>>> Thanks for finding this. >>>>> The change is actually in the assemble script in Bigtop, which should >>>>> leave lib directories and the .txt files in the respective projects >>>>> rather then moving them. >>>>> I see you've already fixed the script. Thanks. >>>>> I will upload the new artifact as soon as it built. There was a >>>>> problem with disk space on ubuntu3. >>>>> >>>>> The question is should we reset the voting period. >>>>> Since there was no change to the Hadoop tree I would rather not, >>>>> unless people ask for it. >>>> >>>>I agree with you: they artifacts are essentially the same, so there's no >>>>need >>>>to reset the vote IMO. >>>> >>>>Cos >>> >>> I am certain that anything that changes the bits in the release and thus >>> the signatures invalidates prior +1's, by Apache policy. >>> I do not know if any reset of the clock is required since there are no >>> functional changes. >>> >>> Each person who voted +1 prior to the change can decide on their own >>>what >>> they need to do to vote +1 again -- that may be only a re-check of the >>> signatures and validation that the change was trivial. >>> >>> In many other projects, even a simple correction of a typo creates a new >>> release candidate. >>> >>> >>> >>>> >>>>> >>>>> Thanks, >>>>> --Konstantin >>>>> >>>>> On Fri, Dec 2, 2011 at 7:34 PM, Roman Shaposhnik <r...@apache.org> >>>>>wrote: >>>>> > On Tue, Nov 29, 2011 at 2:47 AM, Konstantin Shvachko >>>>> > <shv.had...@gmail.com> wrote: >>>>> >> I created a release candidate for hadoop-0.22.0 available for >>>>>review >>>>>at: >>>>> >> http://people.apache.org/~shv/hadoop-0.22.0-rc0/ >>>>> > >>>>> > Pulled this RC into Bigtop and certified the following stack: >>>>> > ═ Hadoop 0.22 >>>>> > ═ HBase 0.92 >>>>> > ═ Zookeeper 3.4.0 >>>>> > >>>>> > Found the following issues (which I suggest we fix and cut RC1): >>>>> > ═1. cd common ; ant -Dcompile.native=true -Dlibrecordio=true >>>>> > -Dlibhdfs=1 -Dfusedfs=true -Dcompile.c++=true api-report bin-package >>>>> > tar >>>>> > ═ ═[copy] Copying 48 files to >>>>> > /tmp/hadoop-0.22.0/common/build/hadoop-common-0.22.0/lib >>>>> > >>>>> > ═ ═BUILD FAILED >>>>> > ═ ═/tmp/hadoop-0.22.0/common/build.xml:1134: >>>>> > ═ ═/tmp/hadoop-0.22.0/common/lib not found. >>>>> > >>>>> > ═ 2. LICENSE.txt, NOTICE.txt and README.txt are missing from under >>>>> > common, hdfs and mapred >>>>> > >>>>> > I will update Bigtop build scripts to take care of missing lib/ >>>>> > creation and also missing files. >>>>> > >>>>> > Once that's done we can cut a new RC when needed. >>>>> > >>>>> > Thanks, >>>>> > Roman. >>> >
