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 <mum...@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 <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.

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>
********************************************/




Reply via email to