Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # general >> [VOTE] Release hadoop-0.22.0-rc0


Copy link to this message
-
Re: [VOTE] Release hadoop-0.22.0-rc0
I am sure things like that are controlled by projects' bylaws that's why
there's nothing specific at the apache level about that. As far as I remember
Hadoop's bylaws don't have any saying wrt a situation like this.

So, I believe the vote is good despite the change in the structure of an
archive which didn't lead to _any_ changes in the functionality.

Cos

On Mon, Dec 05, 2011 at 06:37PM, Konstantin Shvachko wrote:
> Scott,
>
> I did not find anything in Apache policies about invalidating prior
> +1's in case of changing the bits.
> 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.
> 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.
>
> Thanks,
> --Konstantin
>
>
> 2011/12/5 Scott Carey <[EMAIL PROTECTED]>:
> >
> >
> > On 12/3/11 10:52 PM, "Konstantin Boudnik" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> >>> > On Tue, Nov 29, 2011 at 2:47 AM, Konstantin Shvachko
> >>> > <[EMAIL PROTECTED]> 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.
> >