Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of jghoman@gmail.com designates
 209.85.214.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CB02D392.6262F%scott@richrelevance.com>
References: 
 <CAKtuutHfpa3uPCMbMxnj71r5P5khS6hftqfUWeKt3x5BqT2HJA@mail.gmail.com>
 <CB02D392.6262F%scott@richrelevance.com>
From: Jakob Homan <jghoman@gmail.com>
Date: Mon, 5 Dec 2011 21:04:01 -0800
Message-ID: 
 <CADiKvVt1yaKkYXOhfJWyPe=w9FHRpFdG1P6VnVmHrfTY6v3hCA@mail.gmail.com>
Subject: Re: [VOTE] Release hadoop-0.22.0-rc0
To: general@hadoop.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1 on the latest artifacts. Downloaded and verified md5 and signature.

2011/12/5 Scott Carey <scott@richrelevance.com>:
>
>
> On 12/5/11 6:37 PM, "Konstantin Shvachko" <shv.hadoop@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. =C2=A0The rele=
ase
> vote is about the legal aspect of the release artifacts. =C2=A0Are all th=
e
> contents are properly licensed and the package properly cryptographically
> signed? =C2=A0Therefore, if the contents and signatures change even in th=
e 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 o=
f
> 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?). =C2=A0The 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 <scott@richrelevance.com>:
>>>
>>>
>>> On 12/3/11 10:52 PM, "Konstantin Boudnik" <cos@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 n=
o
>>>>need
>>>>to reset the vote IMO.
>>>>
>>>>Cos
>>>
>>> I am certain that anything that changes the bits in the release and thu=
s
>>> 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 ne=
w
>>> release candidate.
>>>
>>>
>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> --Konstantin
>>>>>
>>>>> On Fri, Dec 2, 2011 at 7:34 PM, Roman Shaposhnik <rvs@apache.org>
>>>>>wrote:
>>>>> > On Tue, Nov 29, 2011 at 2:47 AM, Konstantin Shvachko
>>>>> > <shv.hadoop@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:
>>>>> > =E2=95=90 Hadoop 0.22
>>>>> > =E2=95=90 HBase 0.92
>>>>> > =E2=95=90 Zookeeper 3.4.0
>>>>> >
>>>>> > Found the following issues (which I suggest we fix and cut RC1):
>>>>> > =E2=95=901. cd common ; ant -Dcompile.native=3Dtrue -Dlibrecordio=
=3Dtrue
>>>>> > -Dlibhdfs=3D1 -Dfusedfs=3Dtrue -Dcompile.c++=3Dtrue api-report bin-=
package
>>>>> > tar
>>>>> > =E2=95=90 =E2=95=90[copy] Copying 48 files to
>>>>> > /tmp/hadoop-0.22.0/common/build/hadoop-common-0.22.0/lib
>>>>> >
>>>>> > =E2=95=90 =E2=95=90BUILD FAILED
>>>>> > =E2=95=90 =E2=95=90/tmp/hadoop-0.22.0/common/build.xml:1134:
>>>>> > =E2=95=90 =E2=95=90/tmp/hadoop-0.22.0/common/lib not found.
>>>>> >
>>>>> > =E2=95=90 2. LICENSE.txt, NOTICE.txt and README.txt are missing fro=
m 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.
>>>
>