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 20:11:46 GMT
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 <mumrah@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.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>
>>>>>> ********************************************/
>>>>>>
>>>>>>
>>>>>>
>

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