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 <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. > >
signature.asc
Description: Digital signature
