kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jun Rao <jun...@gmail.com>
Subject Re: [VOTE] Apache Kafka Release 0.8.0 - Candidate 5
Date Tue, 03 Dec 2013 06:41:05 GMT
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.



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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message