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 D7C4010CFE for ; Mon, 2 Dec 2013 17:58:01 +0000 (UTC) Received: (qmail 66530 invoked by uid 500); 2 Dec 2013 17:58:00 -0000 Delivered-To: apmail-kafka-dev-archive@kafka.apache.org Received: (qmail 66272 invoked by uid 500); 2 Dec 2013 17:57:59 -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 66264 invoked by uid 99); 2 Dec 2013 17:57:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Dec 2013 17:57:59 +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 (athena.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [209.85.219.54] (HELO mail-oa0-f54.google.com) (209.85.219.54) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Dec 2013 17:57:54 +0000 Received: by mail-oa0-f54.google.com with SMTP id h16so13766226oag.27 for ; Mon, 02 Dec 2013 09:57:33 -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:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=mttgdYu0YvuzFw2L3i3Qd1H3wYPpr6Q03FLr4QbTpvk=; b=h+xfcVSV1F9LNF+EtpN2hgKwkTjAd09wjg+zdYonFGP0yQvW8fQIG2Lol95AibKgVJ 0YlpZlYHU6u38EP44hw1Dbv0pDLz7TgUSPjGTX6cvG60Ek437Yxq1ntFdVAKjDO+kptV oOz+8K98bYcg4KtlOvrfZj1wudCB+8WI71mFMMSQTSjbKsrJK4BwYyqVKjh+o2M0BOWB nuJH6uqWAfDlFcA9SCCTnoUtM+26l9Sf2LvL5vvvSfJeBHklubVPSIFRqZNgapM6yEYX NedCOhoJPV+2UKg6lvYbFehB7XpNMr79kK6aeiqU25fLjZLBNBySJe+vO8LeQ2yp9i5Z +w6Q== X-Gm-Message-State: ALoCoQkAxHzXBFahgCli0GcCmA52MEiGcmyxhYKqmULy/i26o6/XVdl+LpbHU6dI7PnSuGz7Lo8K MIME-Version: 1.0 X-Received: by 10.60.99.71 with SMTP id eo7mr1726080oeb.61.1386007053796; Mon, 02 Dec 2013 09:57:33 -0800 (PST) Received: by 10.182.213.72 with HTTP; Mon, 2 Dec 2013 09:57:33 -0800 (PST) In-Reply-To: References: <529CAE90.4060404@gmail.com> Date: Mon, 2 Dec 2013 12:57:33 -0500 Message-ID: Subject: Re: [VOTE] Apache Kafka Release 0.8.0 - Candidate 5 From: Joe Stein To: "dev@kafka.apache.org" Content-Type: multipart/alternative; boundary=047d7b33d414191f2a04ec90eab1 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b33d414191f2a04ec90eab1 Content-Type: text/plain; charset=ISO-8859-1 Neha, as far as the release process is this what you had in mind https://cwiki.apache.org/confluence/display/KAFKA/Release+Process or different content or more of something or such? Per the POM, I was able to use the artifacts from the maven repository without having to-do anything more than just specifying the artifacts with sbt. resolvers += "Apache Staging" at " https://repository.apache.org/content/groups/staging/" libraryDependencies ++= Seq( ..., "org.apache.kafka" % "kafka_2.10" % "0.8.0", .... ) and on the pure maven side ApacheStaging https://repository.apache.org/content/groups/staging/ ... org.apache.kafka kafka_2.9.2 0.8.0 log4j log4j which very closely mirrors what David was talking about with ivy as well... I didn't really think much of it just a matter of XML we can document (there is actually no using maven documentation on the site at all we should correct that in any case TBD post release) but if folks find it to be a pain then we should definitely fix it for sure. off the top of my head I don't see how to-do that in the Build.scala but I really don't expect it to be too difficult to figure out... the question is do we hold it off for 0.8.1 since technically nothing is breaking (like the null pointer exceptions we had for the bonked pom in beta1 that I shipped to maven central). Before canceling the vote can we at least get consensus to what we are canceling and exactly what fixes should be in RC6 or ... agree to ship RC5 and hold whatever is left for 0.8.1 I am totally fine with working on RC6 (actually just cancelled my plans for the evening because of a whole slew of client work that hit my plate) but I want to make sure we have everything covered that everyone that is voting expects to be in there. David, a few items below don't make sense I sent another email on the thread in regards to the LICENSE /******************************************* Joe Stein Founder, Principal Consultant Big Data Open Source Security LLC http://www.stealth.ly Twitter: @allthingshadoop ********************************************/ On Mon, Dec 2, 2013 at 12:19 PM, Neha Narkhede wrote: > I think we should maintain a wiki describing the release process in detail, > so we save the turnaround time on a release. We can have a VOTE thread to > agree on the release guidelines and follow it. Having said that, it is > worth having the correct .pom file at the very least, since the release is > not very useful if people cannot consume it without pain. > > Thanks, > Neha > > > On Mon, Dec 2, 2013 at 8: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. > > > > 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. > > > > > > > > > > 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 > > > > > > > > > > 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? > > > > I didn't have this issue with java maven pom or scala sbt so maybe > > something more ivy ant specific causing this? 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). > > > > > > > > > > -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 > > >> ********************************************/ > > >> > > >> > > > > > > --047d7b33d414191f2a04ec90eab1--