kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Arthur <mum...@gmail.com>
Subject Re: [VOTE] Apache Kafka Release 0.8.0 - Candidate 5
Date Mon, 02 Dec 2013 18:33:53 GMT
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


Here's a diff of those two: 

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 


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.narkhede@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.stein@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 <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.
>>>> 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>
>>>>> ********************************************/

View raw message