hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Carey <sc...@richrelevance.com>
Subject Re: [VOTE] Release hadoop-0.22.0-rc0
Date Tue, 06 Dec 2011 04:29:07 GMT

On 12/5/11 6:37 PM, "Konstantin Shvachko" <shv.hadoop@gmail.com> wrote:

>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.

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.

>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.

>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 no
>>>to reset the vote IMO.
>> 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
>> 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 <rvs@apache.org>
>>>> > 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
>>>> >> 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.

View raw message