Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@kafka.apache.org
Received-SPF: pass (athena.apache.org: domain of junrao@gmail.com designates
 209.85.219.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <529DE570.3000503@gmail.com>
References: 
 <CAA7ooCDjO+HaXPkWBU3hZ4AYTBbSpUY5qiK8ggY4u2EA1D=t8A@mail.gmail.com>
	<529CAE90.4060404@gmail.com>
	<CAA7ooCC5X5aT0NnAO8_V0tEBjFvWf2JMrVQP-KsLbx0YTot3ew@mail.gmail.com>
	<529CCF1B.4050509@gmail.com>
	<CAFbh0Q170EbWU6rYdGX1AC0H_HrXeGmY9f++np_iLmDs5mNwPg@mail.gmail.com>
	<529DE570.3000503@gmail.com>
Date: Tue, 3 Dec 2013 07:27:57 -0800
Message-ID: 
 <CAFbh0Q1EeJ3=cWvzip=hmL8ZOjXM2YzUfE+jTktK=j=Lhje-_g@mail.gmail.com>
Subject: Re: [VOTE] Apache Kafka Release 0.8.0 - Candidate 5
From: Jun Rao <junrao@gmail.com>
To: "dev@kafka.apache.org" <dev@kafka.apache.org>
Content-Type: multipart/alternative; boundary=001a11c30350ef799704eca2f034

--001a11c30350ef799704eca2f034
Content-Type: text/plain; charset=ISO-8859-1

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 <mumrah@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 <mumrah@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 <mumrah@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
>>>>>> >
>>>>>> ********************************************/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>

--001a11c30350ef799704eca2f034--