kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Stein <joe.st...@stealth.ly>
Subject Re: [VOTE] Apache Kafka Release 0.8.0 - Candidate 5
Date Tue, 03 Dec 2013 19:59:05 GMT
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 <http://www.twitter.com/allthingshadoop>
********************************************/


On Tue, Dec 3, 2013 at 10:27 AM, Jun Rao <junrao@gmail.com> 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 <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
> >>>>>> >
> >>>>>> ********************************************/
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >
>

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