David, I went through the thread and think I capture everything you brought up in JIRA, can you go through and if I missed anything create the JIRA please?
I put the label for each of the JIRA created as "release" . Thanks! /******************************************* 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 1:33 PM, David Arthur <mum...@gmail.com> wrote: > Joe, another thing I noticed in the staging repo: > > The POM for 2.8.2, 2.9.1, 2.9.2, and 2.10 include scala-compiler and some > other stuff that is not included in 2.8.0 > > 2.8.0 https://repository.apache.org/content/groups/staging/org/ > apache/kafka/kafka_2.8.0/0.8.0/kafka_2.8.0-0.8.0.pom > 2.8.2 https://repository.apache.org/content/groups/staging/org/ > apache/kafka/kafka_2.8.2/0.8.0/kafka_2.8.2-0.8.0.pom > > Here's a diff of those two: https://gist.github.com/ > mumrah/7bd6bd8e2805210d5d9d/revisions > > I think maybe the 2.8.0 POM is missing some stuff it needs (zkclient, > snappy, yammer metrics). And there is a duplicate ZK entry for the POMs > >2.8.0 > > -David > > > > > On 12/2/13 12:57 PM, Joe Stein wrote: > >> 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 >> <repositories> >> <repository> >> <id>ApacheStaging</id> >> <url>https://repository.apache.org/content/groups/staging/ >> </url> >> </repository> >> ... >> <dependency> >> <groupId>org.apache.kafka</groupId> >> <artifactId>kafka_2.9.2</artifactId> >> <version>0.8.0</version> >> <exclusions> >> <exclusion> >> <groupId>log4j</groupId> >> <artifactId>log4j</artifactId> >> </exclusion> >> </exclusions> >> </dependency> >> >> 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 <http://www.twitter.com/allthingshadoop> >> ********************************************/ >> >> >> On Mon, Dec 2, 2013 at 12:19 PM, Neha Narkhede <neha.narkh...@gmail.com> >> 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 <joe.st...@stealth.ly> 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 <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. >>>> >>>> >>>> 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 <http://www.twitter.com/allthingshadoop> >>>>>> ********************************************/ >>>>>> >>>>>> >>>>>> >
