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 <mum...@gmail.com> 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 <mum...@gmail.com> 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 <http://www.twitter.com/allthingshadoop> >>>> ********************************************/ >>>> >>>> >>>> On Mon, Dec 2, 2013 at 11:00 AM, David Arthur <mum...@gmail.com> 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 >>>>>> > >>>>>> ********************************************/ >>>>>> >>>>>> >>>>>> >>>>>> >
