Return-Path: X-Original-To: apmail-kafka-dev-archive@www.apache.org Delivered-To: apmail-kafka-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B037610113 for ; Tue, 3 Dec 2013 20:16:09 +0000 (UTC) Received: (qmail 14326 invoked by uid 500); 3 Dec 2013 20:16:09 -0000 Delivered-To: apmail-kafka-dev-archive@kafka.apache.org Received: (qmail 14304 invoked by uid 500); 3 Dec 2013 20:16:09 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 14296 invoked by uid 99); 3 Dec 2013 20:16:09 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Dec 2013 20:16:09 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,LOTS_OF_MONEY,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [209.85.214.182] (HELO mail-ob0-f182.google.com) (209.85.214.182) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Dec 2013 20:16:03 +0000 Received: by mail-ob0-f182.google.com with SMTP id wp4so15205638obc.27 for ; Tue, 03 Dec 2013 12:15:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=NRAC+c0KuBL1oLEImP3w9mQTS2xJWqD4KNip3f0BXeA=; b=XC94G0UeXscYRvGt+UyPz6AyXsqub2ocUqP3qGYf01bha3gtICQp6ZyKvD+aeg9m38 6XitRjjfvqGgyw7Xh7AdAqWg+DKtWRk/bbg211izsDY8TvQgbITg2SmxBqBMwDakHCww rBxZJkEpHLk9ORMqFI/oXZgeFXhDEHzvkAeWmjzrUF5YY8xdDsXMLD0jPXeeQ3JbG1VA /jF0IJueE2ZNMLteJDY1ZDvRekDvjh6oSxlmFMMygvDJRtW1P3HnPDHtSsymhzb3zalu cMHVkwtTOYQ3KJgOSer489Lk1VAHM7bi6ZQECe3blJ9vHa7hTvScHpQyySFEQjl2o8lT 7DDQ== X-Gm-Message-State: ALoCoQln6Dxx6REVTiaOvtU3ZBH/EyV/pQVHzk50FnWxIE8SCRJeNyzjh/B1mvZ0KQVjtZzOsFlY MIME-Version: 1.0 X-Received: by 10.182.98.162 with SMTP id ej2mr2700808obb.61.1386101742064; Tue, 03 Dec 2013 12:15:42 -0800 (PST) Received: by 10.182.213.72 with HTTP; Tue, 3 Dec 2013 12:15:42 -0800 (PST) Date: Tue, 3 Dec 2013 15:15:42 -0500 Message-ID: Subject: [VOTE RESULT] was: [VOTE] Apache Kafka Release 0.8.0 - Candidate 5 From: Joe Stein To: "dev@kafka.apache.org" Content-Type: multipart/alternative; boundary=047d7b2e46f0f56abb04eca6f5b0 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b2e46f0f56abb04eca6f5b0 Content-Type: text/plain; charset=ISO-8859-1 including my vote we have four +1 binding votes non-binding we have one +1 and one -1 votes the release passes I will ship the artifacts to maven central, update the distribution folder and the download page... once all of that is available I will send an ANNOUNCE Thanks everyone! /******************************************* Joe Stein Founder, Principal Consultant Big Data Open Source Security LLC http://www.stealth.ly Twitter: @allthingshadoop ********************************************/ On Tue, Dec 3, 2013 at 2:59 PM, Joe Stein wrote: > verified test, quick start, repository working from sbt and pom maven > > all working as expected for this release. > > verified signatures and crcs > > +1 > > I will call the vote results after I go through the thread and capture all > outstanding issue to move forward to 0.8.1 > > > /******************************************* > Joe Stein > Founder, Principal Consultant > Big Data Open Source Security LLC > http://www.stealth.ly > Twitter: @allthingshadoop > ********************************************/ > > > On Tue, Dec 3, 2013 at 10:27 AM, Jun Rao wrote: > >> There is a difference btw lazy consensus and lazy majority. See >> >> https://cwiki.apache.org/confluence/display/KAFKA/Bylaws#Bylaws-Approvalsfor >> the precise definition. >> >> Thanks, >> >> Jun >> >> >> On Tue, Dec 3, 2013 at 6:06 AM, David Arthur wrote: >> >> > Not to get too side tracked, but I think lazy consensus is supposed to >> > mean "silence gives assent" >> http://www.apache.org/foundation/voting.html# >> > LazyConsensus >> > >> > After the release, we should clean up the language of the bylaws to >> match >> > the language here http://www.apache.org/foundation/glossary.html >> > >> > -David >> > >> > On 12/3/13 1:41 AM, Jun Rao wrote: >> > >> >> The release voting is based on lazy majority ( >> >> https://cwiki.apache.org/confluence/display/KAFKA/Bylaws#Bylaws-Voting >> ). >> >> So >> >> a -1 doesn't kill the release. The question is whether those issues are >> >> really show stoppers. >> >> >> >> Thanks, >> >> >> >> Jun >> >> >> >> >> >> >> >> >> >> On Mon, Dec 2, 2013 at 10:19 AM, David Arthur >> wrote: >> >> >> >> Inline: >> >>> >> >>> >> >>> On 12/2/13 11:59 AM, Joe Stein wrote: >> >>> >> >>> General future thought comment first: lets be careful please to >> raising >> >>>> issues as show stoppers that have been there previously (especially >> if >> >>>> greater than one version previous release back also has the problem) >> and >> >>>> can get fixed in a subsequent release and is only now more pressing >> >>>> because >> >>>> we know about them... seeing something should not necessarily always >> >>>> create >> >>>> priority (sometimes sure, of course but not always that is not the >> best >> >>>> way >> >>>> to manage changes). The VOTE thread should be to artifacts and what >> we >> >>>> are >> >>>> releasing as proper and correct per Apache guidelines... and to make >> >>>> sure >> >>>> that the person doing the release doesn't do something incorrect ... >> >>>> like >> >>>> using the wrong version of JDK to build =8^/. If we are not happy >> with >> >>>> release as ready to ship then lets not call a VOTE and save the >> >>>> prolonged >> >>>> weeks that drag out with so many release candidates. The community >> >>>> suffers >> >>>> from this. >> >>>> >> >>>> +1 If we can get most of this release preparation stuff automated, >> >>> then we >> >>> can iterate on it in a release branch before tagging and voting. >> >>> >> >>> ok, now on to RC5 ...lets extend the vote until 12pm PT tomorrow ... >> >>> >> >>>> hopefully a few more hours for other folks to comment and discuss the >> >>>> issues you raised with my $0.02852425 included below and follow-ups >> as >> >>>> they >> >>>> become necessary... I am also out of pocket in a few hours until >> >>>> tomorrow >> >>>> morning so if it passed I would not be able to publish and announce >> or >> >>>> if >> >>>> failed look towards RC6 anyways =8^) >> >>>> >> >>>> /******************************************* >> >>>> Joe Stein >> >>>> Founder, Principal Consultant >> >>>> Big Data Open Source Security LLC >> >>>> http://www.stealth.ly >> >>>> Twitter: @allthingshadoop > > >> >>>> ********************************************/ >> >>>> >> >>>> >> >>>> On Mon, Dec 2, 2013 at 11:00 AM, David Arthur >> wrote: >> >>>> >> >>>> Seems like most people are verifying the src, so I'll pick on the >> >>>> >> >>>>> binaries >> >>>>> and Maven stuff ;) >> >>>>> >> >>>>> A few problems I see: >> >>>>> >> >>>>> There are some vestigial Git files in the src download: an empty >> .git >> >>>>> and >> >>>>> .gitignore >> >>>>> >> >>>>> Ok, I can do a better job with 0.8.1 but I am not sure this is >> very >> >>>>> >> >>>> different than beta1 and not necessarily a show stopper for 0.8.0 >> >>>> requiring >> >>>> another release candidate, is it? I think updating the release docs >> and >> >>>> rmdir .git after the rm -fr and rm .gitignore moving forward makes >> >>>> sense. >> >>>> >> >>>> Agreed, not a show stopper. >> >>> >> >>> >> >>> In the source download, I see the SBT license in LICENSE which >> seems >> >>>> >> >>>>> correct (since we distribute an SBT binary), but in the binary >> >>>>> download I >> >>>>> see the same license. Don't we need the Scala license ( >> >>>>> http://www.scala-lang.org/license.html) in the binary distribution? >> >>>>> >> >>>>> I fixed this already not only in the binary release >> >>>>> >> >>>> https://issues.apache.org/jira/browse/KAFKA-1131 but also in the JAR >> >>>> files >> >>>> that are published to Maven >> >>>> https://issues.apache.org/jira/browse/KAFKA-1133are you checking >> from >> >>>> http://people.apache.org/~joestein/kafka-0.8.0-candidate5/ because I >> >>>> just >> >>>> downloaded again and it looks alright to me. If not then definitely >> >>>> this >> >>>> RC should be shot down because it does not do what we are saying it >> is >> >>>> doing.. but if it is wrong can you be more specific and create a JIRA >> >>>> with >> >>>> the fix because I thought I got it right already... but if not then >> lets >> >>>> get it right because that is why we pulled the release in RC3 >> >>>> >> >>>> The LICENSE file in both the src and binary downloads includes "SBT >> >>> LICENSE" at the end. I could be wrong, but I think the src download >> >>> should >> >>> include the SBT licnese and the binary download should include the >> Scala >> >>> license. Since we have released in the past without proper licensing, >> >>> it's >> >>> probably not a huge deal to do it again (but we should fix it). >> >>> >> >>> >> >>> I create a simple Ant+Ivy project to test resolving the artifacts >> >>>> >> >>>>> published to Apache staging repo: >> https://github.com/mumrah/kafka-ivy. >> >>>>> This will fetch Kafka libs from the Apache staging area and other >> >>>>> things >> >>>>> from Maven Central. It will fetch the jars into lib/ivy/{conf} and >> >>>>> generate >> >>>>> a report of the dependencies, conflicts, and licenses into >> ivy-report. >> >>>>> Notice I had to add three exclusions to get things working. Maybe we >> >>>>> should >> >>>>> add these to our pom? >> >>>>> >> >>>>> I don't think this is a showstopper is it? can't this wait for >> 0.8.1 >> >>>>> >> >>>> and >> >>>> not hold up the 0.8.0 release? >> >>>> >> >>>> No I don't think it's a show stopper. But to Neha's point, a >> painless >> >>> Maven/Ivy/SBT/Gradle integration is important since this is how most >> >>> users >> >>> interface with Kafka. That said, ZooKeeper is what's pulling in these >> >>> troublesome deps and it doesn't stop people from using ZooKeeper. I >> can >> >>> live with this. >> >>> >> >>> >> >>> I didn't have this issue with java maven pom or scala sbt so maybe >> >>>> something more ivy ant specific causing this? >> >>>> >> >>>> No clue... maybe? I run into these deps all the time when dealing >> with >> >>> ZooKeeper. >> >>> >> >>> folks use gradle too so I >> >>> >> >>>> expect some feedback at some point to that working or not perhaps in >> >>>> 0.8.1 >> >>>> or even 0.9 we can try to cover every way everyone uses and make sure >> >>>> they >> >>>> are all good to go moving forward... perhaps even some vagrant, >> docker, >> >>>> puppet and chef love too (which I can contribute if folks are >> >>>> interested) >> >>>> =8^) >> >>>> >> >>>> >> >>> In any case can you create a JIRA and throw a patch up on it please, >> >>>> thanks! IMHO this is for 0.8.1 though ... what are thoughts here... >> >>>> >> >>>> >> >>>> I think I'll have to -1 the release due to the missing Scala >> license >> >>>> in >> >>>> >> >>>>> the binary dist. We should check the other licenses as well (see >> >>>>> ivy-report >> >>>>> from my little Ant project). >> >>>>> >> >>>>> it would break my heart to have lots of binding +1 votes and 2 >> >>>>> >> >>>> non-binding >> >>>> votes one +1 and one -1, I still haven't cast my vote yet was hoping >> >>>> everyone would get their voices and everything in before calling the >> >>>> VOTE >> >>>> closed or canceled. I really don't mind preparing a release >> candidate 6 >> >>>> that is not the issue at all but I think we need to be thoughtful >> about >> >>>> using the release candidates to fixe things that should be fixed and >> >>>> part >> >>>> of the releases themselves where the release candidates are to make >> sure >> >>>> that the preparation of the build is not wrong (like it was in RC4 >> >>>> where I >> >>>> used JDK 7 by accident). >> >>>> >> >>>> Does one -1 kill the vote? I'm mainly trying to be the squeaky wheel >> >>> here >> >>> ;) - I'd rather not hold up the release and just fix these issues for >> >>> 0.8.1. >> >>> >> >>> >> >>> -David >> >>>> >> >>>>> >> >>>>> On 11/26/13 5:34 PM, Joe Stein wrote: >> >>>>> >> >>>>> This is the fifth candidate for release of Apache Kafka 0.8.0. >> This >> >>>>> >> >>>>>> release candidate is now built from JDK 6 as RC4 was built with >> JDK 7. >> >>>>>> >> >>>>>> Release Notes for the 0.8.0 release >> >>>>>> http://people.apache.org/~joestein/kafka-0.8.0- >> >>>>>> candidate5/RELEASE_NOTES.html >> >>>>>> >> >>>>>> *** Please download, test and vote by Monday December, 2nd, 12pm >> PDT >> >>>>>> >> >>>>>> Kafka's KEYS file containing PGP keys we use to sign the release: >> >>>>>> http://svn.apache.org/repos/asf/kafka/KEYS in addition to the md5 >> and >> >>>>>> sha1 >> >>>>>> checksum >> >>>>>> >> >>>>>> * Release artifacts to be voted upon (source and binary): >> >>>>>> http://people.apache.org/~joestein/kafka-0.8.0-candidate5/ >> >>>>>> >> >>>>>> * Maven artifacts to be voted upon prior to release: >> >>>>>> https://repository.apache.org/content/groups/staging/ >> >>>>>> >> >>>>>> (i.e. in sbt land this can be added to the build.sbt to use Kafka >> >>>>>> resolvers += "Apache Staging" at " >> >>>>>> https://repository.apache.org/content/groups/staging/" >> >>>>>> libraryDependencies += "org.apache.kafka" % "kafka_2.10" % "0.8.0" >> >>>>>> ) >> >>>>>> >> >>>>>> * The tag to be voted upon (off the 0.8 branch) is the 0.8.0 tag >> >>>>>> https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=tag;h= >> >>>>>> 2c20a71a010659e25af075a024cbd692c87d4c89 >> >>>>>> >> >>>>>> /******************************************* >> >>>>>> Joe Stein >> >>>>>> Founder, Principal Consultant >> >>>>>> Big Data Open Source Security LLC >> >>>>>> http://www.stealth.ly >> >>>>>> Twitter: @allthingshadoop < >> http://www.twitter.com/allthingshadoop >> >>>>>> > >> >>>>>> ********************************************/ >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> > >> > > --047d7b2e46f0f56abb04eca6f5b0--