hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Homan <jgho...@gmail.com>
Subject Re: [VOTE] Release hadoop-0.22.0-rc0
Date Tue, 06 Dec 2011 05:04:01 GMT
+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.  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 <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
>>>>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 <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:
>>>>> > ═ 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.
>>>
>

Mime
View raw message