Hi,

This is the second candidate for the first incubator release for
Apache Kafka, version 0.7.0-incubating.
This fixes a bunch of Apache license header issues that were found in
the first candidate.

It also fixes the following issues:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-2/RELEASE-NOTES.html

*** Please download, test and vote by noon Oct, 14th, 5 pm

Note that we are voting upon the source (tag), binaries are provided
for convenience.

Source and binary files:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-2/

The tag to be voted upon:
http://svn.apache.org/repos/asf/incubator/kafka/tags/kafka-0.7.0-incubating-candidate-2

Kafka's KEYS file containing PGP keys we use to sign the release:
http://svn.apache.org/repos/asf/incubator/kafka/trunk/KEYS

Note that the Incubator PMC needs to vote upon the release after a
successful PPMC vote before
any release can be made official.

Thanks,
Neha

-1  there are lot of Rat failures.

We should also delete the older tags since these have not been released.
Regards,
Alan

On Oct 11, 2011, at 6:57 PM, Neha Narkhede wrote:

> Hi,
>
> This is the second candidate for the first incubator release for
> Apache Kafka, version 0.7.0-incubating.
> This fixes a bunch of Apache license header issues that were found in
> the first candidate.
>
> It also fixes the following issues:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-2/RELEASE-NOTES.html
>
> *** Please download, test and vote by noon Oct, 14th, 5 pm
>
> Note that we are voting upon the source (tag), binaries are provided
> for convenience.
>
> Source and binary files:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-2/
>
> The tag to be voted upon:
> http://svn.apache.org/repos/asf/incubator/kafka/tags/kafka-0.7.0-incubating-candidate-2
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> http://svn.apache.org/repos/asf/incubator/kafka/trunk/KEYS
>
> Note that the Incubator PMC needs to vote upon the release after a
> successful PPMC vote before
> any release can be made official.
>
> Thanks,
> Neha

Hi,

Please take a look at the patches submitted to KAFKA-151 & KAFKA-143.
With those 2 patches,
we have a clean rat output, provided the .rat-excludes contents are
agreeable to people.

Also, the older RC1 tag is deleted from svn, and the KEYS file is
moved to kafka root, from trunk.

Thanks,
Neha

On Wed, Oct 12, 2011 at 7:31 AM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
> -1  there are lot of Rat failures.
>
> We should also delete the older tags since these have not been released.
>
>
> Regards,
> Alan
>
> On Oct 11, 2011, at 6:57 PM, Neha Narkhede wrote:
>
>> Hi,
>>
>> This is the second candidate for the first incubator release for
>> Apache Kafka, version 0.7.0-incubating.
>> This fixes a bunch of Apache license header issues that were found in
>> the first candidate.
>>
>> It also fixes the following issues:
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-2/RELEASE-NOTES.html
>>
>> *** Please download, test and vote by noon Oct, 14th, 5 pm
>>
>> Note that we are voting upon the source (tag), binaries are provided
>> for convenience.
>>
>> Source and binary files:
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-2/
>>
>> The tag to be voted upon:
>> http://svn.apache.org/repos/asf/incubator/kafka/tags/kafka-0.7.0-incubating-candidate-2
>>
>> Kafka's KEYS file containing PGP keys we use to sign the release:
>> http://svn.apache.org/repos/asf/incubator/kafka/trunk/KEYS
>>
>> Note that the Incubator PMC needs to vote upon the release after a
>> successful PPMC vote before
>> any release can be made official.
>>
>> Thanks,
>> Neha
>
>

On Oct 12, 2011, at 12:30 PM, Neha Narkhede wrote:

> Hi,
>
> Please take a look at the patches submitted to KAFKA-151 & KAFKA-143.
> With those 2 patches,
> we have a clean rat output, provided the .rat-excludes contents are
> agreeable to people.

Seems pretty good to me.

> Also, the older RC1 tag is deleted from svn, and the KEYS file is
> moved to kafka root, from trunk.

As I mentioned before, trunk or root, it's up to you guys.
Regards,
Alan

Hi,

This is the third candidate for the first incubator release for Apache
Kafka, version 0.7.0-incubating. This fixes ALL rat failures and also
adds a standard .rat-excludes
files along with rat scripts to Kafka.

It fixes the following issues:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-3/RELEASE-NOTES.html

*** Please download, test and vote by noon Oct, 18th, 6 pm

Note that we are voting upon the source (tag), binaries are provided
for convenience.

Source and binary files:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-3/

The tag to be voted upon:
http://svn.apache.org/repos/asf/incubator/kafka/tags/kafka-0.7.0-incubating-candidate-3

Kafka's KEYS file containing PGP keys we use to sign the release:
http://svn.apache.org/repos/asf/incubator/kafka/KEYS

Note that the Incubator PMC needs to vote upon the release after a
successful PPMC vote before
any release can be made official.

Thanks,
Neha

>> To recap, all the artifacts that are going to be published as part of the release have to be provided for review.  Artifacts cannot be published after the fact even though they may be built from a tag.

So since KAFKA-133 is not yet resolved and will take quite some sbt
specific work, we can pass on that for this release. We can start
publishing to Maven after the next release.

Seems like we are unblocked on voting for this RC then. Lets start the
vote, the deadline is still Oct 18th, 6pm

Thanks,
Neha
On Fri, Oct 14, 2011 at 11:37 AM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>
> On Oct 14, 2011, at 11:21 AM, Neha Narkhede wrote:
>
>> Alan,
>>
>> Thanks for looking into this.
>>
>>> The binary tgz should not be offered to assist in the review unless you're going to publish it as well, i.e. provide it as a download.  Signing it will only make people think you're going to publish it.  Not a showstopper.  Something to consider next time.
>>
>> Yes. We intend to publish the tgz too. That helps users run the
>> quickstart and unit tests on a release quickly. I checked some other
>> incubator projects and top-level Apache projects. They seemed to do
>> the same.
>
> Yes, that's fine.  Your statement "binaries are provided for convenience" is what confused me.  When a vote occurs all the artifacts and their signatures that will be published should be provided for review.
>
>>
>>> IIRC, the actual artifacts that get published to maven should also be available to review.  http://www.apache.org/dev/publishing-maven-artifacts.html
>>
>> We actually haven't yet resolved
>> https://issues.apache.org/jira/browse/KAFKA-133. From what you had
>> mentioned, our understanding was that you have to wait for at least
>> one release to be able to publish to a Maven repo. Do you think this
>> blocks us ?
>
> If it's the intention of the project to publish Maven artifacts as part of this release then they need to be provided following the guidelines outlined in http://www.apache.org/dev/publishing-maven-artifacts.html.  This means that KAFKA-133 needs to be resolved before the vote.  Maven artifacts cannot be published after the fact even though they may be built from a tag.
>
> To recap, all the artifacts that are going to be published as part of the release have to be provided for review.  Artifacts cannot be published after the fact even though they may be built from a tag.
>
>>> Is kafka-0.7.0-incubating-candidate-3 the intended final tag?  If not maybe it should just be kafka-0.7.0-incubating.  Once this goes out you can never change it.
>>
>> I'm thinking that since RC3 and the release tag is the same, we can
>> add the kafka-0.7.0-incubating tag and delete the
>> kafka-0.7.0-incubating-candidate-3 tag.
>
> Simply moving the tag should be fine unless you want to pick up more stuff from trunk.
>
>
> Regards,
> Alan
>
>>
>> Let us know if this sounds good.
>>
>> Thanks,
>> Neha
>>
>> On Thu, Oct 13, 2011 at 9:26 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>>> The binary tgz should not be offered to assist in the review unless you're going to publish it as well, i.e. provide it as a download.  Signing it will only make people think you're going to publish it.  Not a showstopper.  Something to consider next time.
>>>
>>> IIRC, the actual artifacts that get published to maven should also be available to review.  http://www.apache.org/dev/publishing-maven-artifacts.html
>>>
>>> Is kafka-0.7.0-incubating-candidate-3 the intended final tag?  If not maybe it should just be kafka-0.7.0-incubating.  Once this goes out you can never change it.
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>> On Oct 13, 2011, at 6:54 PM, Neha Narkhede wrote:
>>>
>>>> Hi,
>>>>
>>>> This is the third candidate for the first incubator release for Apache
>>>> Kafka, version 0.7.0-incubating. This fixes ALL rat failures and also
>>>> adds a standard .rat-excludes
>>>> files along with rat scripts to Kafka.
>>>>
>>>> It fixes the following issues:
>>>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-3/RELEASE-NOTES.html

On Oct 14, 2011, at 11:51 AM, Neha Narkhede wrote:

>>> To recap, all the artifacts that are going to be published as part of the release have to be provided for review.  Artifacts cannot be published after the fact even though they may be built from a tag.
>
> So since KAFKA-133 is not yet resolved and will take quite some sbt
> specific work, we can pass on that for this release. We can start
> publishing to Maven after the next release.

That's fine.  What do others in the community think about this?  Were they counting on a release of Maven artifacts as well?  If that's what is everyone's understanding then the release should be good on this front.

Were you going to rebuild the tgz so that it did not have the candidate-3 bit in its path?  What about the rename of the tag?  If you change any of these you need to restart the vote since this email is the record of what's been voted on.  

Thanks for being so patent.  Getting the first release out for an incubating project always has its fits and starts.

Regards,
Alan

Alan,

>> Were you going to rebuild the tgz so that it did not have the candidate-3 bit in its path?  What about the rename of the tag?  If you change any of these you need to restart the vote since this email is the record of what's been voted on.

We intended to let people vote on the RC3, let the vote pass, and then
just rename the tag and tgz to remove the "-candidate-3" from the
name. The contents will stay the same. Our understanding is that if
the contents stay the same, we don't need another vote. Is that right
?

Thanks,
Neha

On Fri, Oct 14, 2011 at 12:44 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>
> On Oct 14, 2011, at 11:51 AM, Neha Narkhede wrote:
>
>>>> To recap, all the artifacts that are going to be published as part of the release have to be provided for review.  Artifacts cannot be published after the fact even though they may be built from a tag.
>>
>> So since KAFKA-133 is not yet resolved and will take quite some sbt
>> specific work, we can pass on that for this release. We can start
>> publishing to Maven after the next release.
>
> That's fine.  What do others in the community think about this?  Were they counting on a release of Maven artifacts as well?  If that's what is everyone's understanding then the release should be good on this front.
>
> Were you going to rebuild the tgz so that it did not have the candidate-3 bit in its path?  What about the rename of the tag?  If you change any of these you need to restart the vote since this email is the record of what's been voted on.
>
> Thanks for being so patent.  Getting the first release out for an incubating project always has its fits and starts.
>
>
>
> Regards,
> Alan
>
>

On Oct 14, 2011, at 1:08 PM, Neha Narkhede wrote:

> Alan,
>
>>> Were you going to rebuild the tgz so that it did not have the candidate-3 bit in its path?  What about the rename of the tag?  If you change any of these you need to restart the vote since this email is the record of what's been voted on.
>
> We intended to let people vote on the RC3, let the vote pass, and then
> just rename the tag and tgz to remove the "-candidate-3" from the
> name. The contents will stay the same.

The *contents* will contain the "-candidate-3".  Not sure why the project would want that especially since you intend to rename the tag.  Also, when you rename the tag there's no way to tell from the proposal that's being voted on that this is what happened.  

> Our understanding is that if
> the contents stay the same, we don't need another vote. Is that right
> ?

Restarting the vote is very common even for well established projects.  It's to be expected for podlings that are working out the kinks.  I wouldn't worry about it.
Regards,
Alan

>
> Thanks,
> Neha
>
> On Fri, Oct 14, 2011 at 12:44 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>>
>> On Oct 14, 2011, at 11:51 AM, Neha Narkhede wrote:
>>
>>>>> To recap, all the artifacts that are going to be published as part of the release have to be provided for review.  Artifacts cannot be published after the fact even though they may be built from a tag.
>>>
>>> So since KAFKA-133 is not yet resolved and will take quite some sbt
>>> specific work, we can pass on that for this release. We can start
>>> publishing to Maven after the next release.
>>
>> That's fine.  What do others in the community think about this?  Were they counting on a release of Maven artifacts as well?  If that's what is everyone's understanding then the release should be good on this front.
>>
>> Were you going to rebuild the tgz so that it did not have the candidate-3 bit in its path?  What about the rename of the tag?  If you change any of these you need to restart the vote since this email is the record of what's been voted on.
>>
>> Thanks for being so patent.  Getting the first release out for an incubating project always has its fits and starts.
>>
>>
>>
>> Regards,
>> Alan
>>
>>

> The *contents* will contain the "-candidate-3".  Not sure why the project would want that especially since you intend to rename the tag.  Also, when you rename the tag there's no way to tell from the proposal that's being voted on that this is what happened.

As long as the signature and MD5 don't change, renaming the artifact
is fine (though it's more convenient for the release manager to put
the final artifacts in a <version>-RC<n> directory). In this case, the
tarball unpacks to "kafka-0.7.0-incubating-candidate-3", which is kind
of unfortunate. Might as well clean that up.

It's a software release, not a shuttle launch. Is this the only
outstanding issue (I saw that RAT passed in KAFKA-143)? JIRA looks
clean.

We should find someone to sign the release key. -C

On Fri, Oct 14, 2011 at 1:18 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>
> On Oct 14, 2011, at 1:08 PM, Neha Narkhede wrote:
>
>> Alan,
>>
>>>> Were you going to rebuild the tgz so that it did not have the candidate-3 bit in its path?  What about the rename of the tag?  If you change any of these you need to restart the vote since this email is the record of what's been voted on.
>>
>> We intended to let people vote on the RC3, let the vote pass, and then
>> just rename the tag and tgz to remove the "-candidate-3" from the
>> name. The contents will stay the same.
>
> The *contents* will contain the "-candidate-3".  Not sure why the project would want that especially since you intend to rename the tag.  Also, when you rename the tag there's no way to tell from the proposal that's being voted on that this is what happened.
>
>> Our understanding is that if
>> the contents stay the same, we don't need another vote. Is that right
>> ?
>
> Restarting the vote is very common even for well established projects.  It's to be expected for podlings that are working out the kinks.  I wouldn't worry about it.
>
>
> Regards,
> Alan
>
>>
>> Thanks,
>> Neha
>>
>> On Fri, Oct 14, 2011 at 12:44 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>>>
>>> On Oct 14, 2011, at 11:51 AM, Neha Narkhede wrote:
>>>
>>>>>> To recap, all the artifacts that are going to be published as part of the release have to be provided for review.  Artifacts cannot be published after the fact even though they may be built from a tag.
>>>>
>>>> So since KAFKA-133 is not yet resolved and will take quite some sbt
>>>> specific work, we can pass on that for this release. We can start
>>>> publishing to Maven after the next release.
>>>
>>> That's fine.  What do others in the community think about this?  Were they counting on a release of Maven artifacts as well?  If that's what is everyone's understanding then the release should be good on this front.
>>>
>>> Were you going to rebuild the tgz so that it did not have the candidate-3 bit in its path?  What about the rename of the tag?  If you change any of these you need to restart the vote since this email is the record of what's been voted on.
>>>
>>> Thanks for being so patent.  Getting the first release out for an incubating project always has its fits and starts.
>>>
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>>
>
>

Chris,

>> In this case, the tarball unpacks to "kafka-0.7.0-incubating-candidate-3", which is kind of unfortunate. Might as well clean that up.

I agree. In this case, we'd need to rename the directory as well,
which would change the MD5, so I guess that needs another vote.

Going forward, we want to confirm the exact process to follow for
publishing a release. Let me state our understanding here. Please
correct
us now, if you don't agree with the following

For example, we are release RC1 for Kafka 0.7.0-incubating -

1. Create tgz named kafka-0.7.0-incubating.tar.gz
2. Create the PGP signature for it - kafka-0.7.0-incubating.tar.gz.asc
3. Create the MD5 signature for it - kafka-0.7.0-incubating.tar.gz.md5
4. Specify the svn revision to be voted upon. For example,
http://svn.apache.org/repos/asf/incubator/kafka/trunk@r1181176
5. Upload the tgz to a URL that looks like
http://*/kafka-0.7.0-incubating-candidate-1/

Now, say if RC1 vote doesn't pass -

1. Fix the bugs in RC1
2. Create tgz named kafka-0.7.0-incubating.tar.gz
3. Create the PGP signature for it - kafka-0.7.0-incubating.tar.gz.asc
4. Create the MD5 signature for it - kafka-0.7.0-incubating.tar.gz.md5
5. Specify the NEW svn revision to be voted upon. For example,
http://svn.apache.org/repos/asf/incubator/kafka/trunk@r1181186
6. Upload the tgz to a URL that looks like
http://*/kafka-0.7.0-incubating-candidate-2/

If RC1 vote passes, then -

1. Create svn tag named kafka-0.7.0-incubating, pointing to the SVN
revision that was voted upon
2. Upload the tgz to a URL that looks like http://*/kafka-0.7.0-incubating/

It will be good to iron this out once and follow it in the forthcoming releases.
We plan to use this process to start a new vote on Monday morning, Oct 17th.
Please let us know if this process looks good to the mentors.

Thanks,
Neha

On Fri, Oct 14, 2011 at 2:06 PM, Chris Douglas <[EMAIL PROTECTED]> wrote:
>> The *contents* will contain the "-candidate-3".  Not sure why the project would want that especially since you intend to rename the tag.  Also, when you rename the tag there's no way to tell from the proposal that's being voted on that this is what happened.
>
> As long as the signature and MD5 don't change, renaming the artifact
> is fine (though it's more convenient for the release manager to put
> the final artifacts in a <version>-RC<n> directory). In this case, the
> tarball unpacks to "kafka-0.7.0-incubating-candidate-3", which is kind
> of unfortunate. Might as well clean that up.
>
> It's a software release, not a shuttle launch. Is this the only
> outstanding issue (I saw that RAT passed in KAFKA-143)? JIRA looks
> clean.
>
> We should find someone to sign the release key. -C
>
> On Fri, Oct 14, 2011 at 1:18 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>>
>> On Oct 14, 2011, at 1:08 PM, Neha Narkhede wrote:
>>
>>> Alan,
>>>
>>>>> Were you going to rebuild the tgz so that it did not have the candidate-3 bit in its path?  What about the rename of the tag?  If you change any of these you need to restart the vote since this email is the record of what's been voted on.
>>>
>>> We intended to let people vote on the RC3, let the vote pass, and then
>>> just rename the tag and tgz to remove the "-candidate-3" from the
>>> name. The contents will stay the same.
>>
>> The *contents* will contain the "-candidate-3".  Not sure why the project would want that especially since you intend to rename the tag.  Also, when you rename the tag there's no way to tell from the proposal that's being voted on that this is what happened.
>>
>>> Our understanding is that if
>>> the contents stay the same, we don't need another vote. Is that right
>>> ?
>>
>> Restarting the vote is very common even for well established projects.  It's to be expected for podlings that are working out the kinks.  I wouldn't worry about it.
>>
>>
>> Regards,
>> Alan
>>
>>>
>>> Thanks,
>>> Neha
>>>
>>> On Fri, Oct 14, 2011 at 12:44 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>>>>

On 10/14/2011 03:44 PM, Alan D. Cabrera wrote:
> That's fine.  What do others in the community think about this?  Were
> they counting on a release of Maven artifacts as well?  If that's
> what is everyone's understanding then the release should be good on
> this front.

My expectation was that maven artifacts were a "after the first release"
thing.  I don't recall anyone expressing expectations to the contrary.

Hi,

This is the fourth candidate for the first incubator release for
Apache Kafka, version 0.7.0-incubating.
There are *no* code changes since candidate 3. This candidate is
published to follow the updated release
process for Kafka.

It fixes the following issues:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-4/RELEASE-NOTES.html

*** Please download, test and vote by Oct, 20th, 10 am

Note that we are voting upon the source (revision), binaries are
provided for convenience.

Source and binary files:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-4/

The SVN revision to be voted upon:
https://svn.apache.org/repos/asf/incubator/kafka/0.7@1185297

Kafka's KEYS file containing PGP keys we use to sign the release:
http://svn.apache.org/repos/asf/incubator/kafka/KEYS

Note that the Incubator PMC needs to vote upon the release after a
successful PPMC vote before
any release can be made official.

Thanks,
Neha

On Oct 17, 2011, at 10:45 AM, Neha Narkhede wrote:

> Hi,
>
> This is the fourth candidate for the first incubator release for
> Apache Kafka, version 0.7.0-incubating.
> There are *no* code changes since candidate 3. This candidate is
> published to follow the updated release
> process for Kafka.
>
> It fixes the following issues:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-4/RELEASE-NOTES.html
>
> *** Please download, test and vote by Oct, 20th, 10 am
>
> Note that we are voting upon the source (revision), binaries are
> provided for convenience.

Since this is a _source_ release I'm not sure there should be binaries, e.g. kafka-*.jar, *.class, files in the distribution.  The d/l is 50M.  Up to you guys.

> Source and binary files:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-4/
>
> The SVN revision to be voted upon:
> https://svn.apache.org/repos/asf/incubator/kafka/0.7@1185297

I thought the plan was to vote off of trunk, e.g.

> 5. Specify the NEW svn revision to be voted upon. For example,
> http://svn.apache.org/repos/asf/incubator/kafka/trunk@r1181186

Shouldn't 0.7 be in branches or tags?  Once the vote goes through the project will be stuck with kafka/0.7.  Is this what you guys want?
Regards,
Alan

Any combination of repository tweaks are valid as long as it's clear
what people are voting on. The signatures/etc. are helpful mechanisms
to ensure nobody is confused, but it's possible to get carried away.
You don't need to follow a specific incantation to generate a valid
release, as long as the artifact approved by the voters is
unambiguously identified. Identifying it in the repository is just
good release management.

One release process that's worked in the past (completely
optional/pedantic steps in square brackets):

Let ROOT be http://svn.apache.org/repos/asf/incubator/kafka
Let VERSION be a version string, e.g. kafka-0.5.0-incubating
[1.] If releasing a new minor version (x.y), create a branch at
$ROOT/branches/$VERSION; patch releases x.y.z don't need branches)
2. Modify CHANGES.txt, follow whatever packaging is appropriate for the release
3. Create an tarball from that branch, contents matching the final release
4. Create signature/MD5 and upload to people.apache.org/~username/$VERSION-$RC
[5.] Create a tag in the repository at $ROOT/tags/$VERSION-$RC
6. Run a vote pointing to the artifact/tag
7. If the vote fails or problems are found, bump $RC, fix on
branch/trunk, and goto 3
[8.] Rename the tag of the approved $RC to $VERSION, cleaning up other RC tags

The above is pretty much exactly what you described, but adding a
release branch and RC tags (again, just a convenience for devs). If
you're only releasing from trunk, you probably don't need a release
branch, but they're cheap and often useful. -C

On Fri, Oct 14, 2011 at 4:42 PM, Neha Narkhede <[EMAIL PROTECTED]> wrote:
> 1. Create tgz named kafka-0.7.0-incubating.tar.gz
> 2. Create the PGP signature for it - kafka-0.7.0-incubating.tar.gz.asc
> 3. Create the MD5 signature for it - kafka-0.7.0-incubating.tar.gz.md5
> 4. Specify the svn revision to be voted upon. For example,
> http://svn.apache.org/repos/asf/incubator/kafka/trunk@r1181176
> 5. Upload the tgz to a URL that looks like
> http://*/kafka-0.7.0-incubating-candidate-1/
>
> Now, say if RC1 vote doesn't pass -
>
> 1. Fix the bugs in RC1
> 2. Create tgz named kafka-0.7.0-incubating.tar.gz
> 3. Create the PGP signature for it - kafka-0.7.0-incubating.tar.gz.asc
> 4. Create the MD5 signature for it - kafka-0.7.0-incubating.tar.gz.md5
> 5. Specify the NEW svn revision to be voted upon. For example,
> http://svn.apache.org/repos/asf/incubator/kafka/trunk@r1181186
> 6. Upload the tgz to a URL that looks like
> http://*/kafka-0.7.0-incubating-candidate-2/
>
> If RC1 vote passes, then -
>
> 1. Create svn tag named kafka-0.7.0-incubating, pointing to the SVN
> revision that was voted upon
> 2. Upload the tgz to a URL that looks like http://*/kafka-0.7.0-incubating/
>
> It will be good to iron this out once and follow it in the forthcoming releases.
> We plan to use this process to start a new vote on Monday morning, Oct 17th.
> Please let us know if this process looks good to the mentors.
>
> Thanks,
> Neha
>
> On Fri, Oct 14, 2011 at 2:06 PM, Chris Douglas <[EMAIL PROTECTED]> wrote:
>>> The *contents* will contain the "-candidate-3".  Not sure why the project would want that especially since you intend to rename the tag.  Also, when you rename the tag there's no way to tell from the proposal that's being voted on that this is what happened.
>>
>> As long as the signature and MD5 don't change, renaming the artifact
>> is fine (though it's more convenient for the release manager to put
>> the final artifacts in a <version>-RC<n> directory). In this case, the
>> tarball unpacks to "kafka-0.7.0-incubating-candidate-3", which is kind
>> of unfortunate. Might as well clean that up.
>>
>> It's a software release, not a shuttle launch. Is this the only
>> outstanding issue (I saw that RAT passed in KAFKA-143)? JIRA looks
>> clean.
>>
>> We should find someone to sign the release key. -C
>>
>> On Fri, Oct 14, 2011 at 1:18 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>>>
>>> On Oct 14, 2011, at 1:08 PM, Neha Narkhede wrote:

+1

Ran tests, MD5/signature match. Assuming RAT still passes with 0
failures per KAFKA-143. Assuming licenses are all approved, per
KAFKA-142.

I did get one test failure:

[info] Test Starting: testLoadBalance(kafka.zk.ZKLoadBalanceTest)
[error] Test Failed: testLoadBalance(kafka.zk.ZKLoadBalanceTest)
junit.framework.AssertionFailedError: expected:<5> but was:<2>
[snip]
        at kafka.zk.ZKLoadBalanceTest.checkSetEqual(ZKLoadBalanceTest.scala:121)
        at kafka.zk.ZKLoadBalanceTest.testLoadBalance(ZKLoadBalanceTest.scala:89)

-C

On Mon, Oct 17, 2011 at 10:45 AM, Neha Narkhede <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This is the fourth candidate for the first incubator release for
> Apache Kafka, version 0.7.0-incubating.
> There are *no* code changes since candidate 3. This candidate is
> published to follow the updated release
> process for Kafka.
>
> It fixes the following issues:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-4/RELEASE-NOTES.html
>
> *** Please download, test and vote by Oct, 20th, 10 am
>
> Note that we are voting upon the source (revision), binaries are
> provided for convenience.
>
> Source and binary files:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-4/
>
> The SVN revision to be voted upon:
> https://svn.apache.org/repos/asf/incubator/kafka/0.7@1185297
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>
> Note that the Incubator PMC needs to vote upon the release after a
> successful PPMC vote before
> any release can be made official.
>
> Thanks,
> Neha
>

On Mon, Oct 17, 2011 at 11:39 AM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>> 5. Specify the NEW svn revision to be voted upon. For example,
>> http://svn.apache.org/repos/asf/incubator/kafka/trunk@r1181186
>
> Shouldn't 0.7 be in branches or tags?  Once the vote goes through the project will be stuck with kafka/0.7.  Is this what you guys want?

Why would the project be stuck with it? The repository can always be
rearranged, right?

For integration with SVN tools, using the
ROOT/{branches,tags}/$version layout is probably worthwhile. If it's a
branch, just move it into place. -C

>> Why would the project be stuck with it? The repository can always berearranged, right?

Yeah, that was overlooked by me while creating the branch. We thought
that we will
just rearrange the repo after the vote to fix the /branches/0.7 path.

Thanks for the clarification Chris !

-Neha

On Mon, Oct 17, 2011 at 1:32 PM, Chris Douglas <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 17, 2011 at 11:39 AM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>>> 5. Specify the NEW svn revision to be voted upon. For example,
>>> http://svn.apache.org/repos/asf/incubator/kafka/trunk@r1181186
>>
>> Shouldn't 0.7 be in branches or tags?  Once the vote goes through the project will be stuck with kafka/0.7.  Is this what you guys want?
>
> Why would the project be stuck with it? The repository can always be
> rearranged, right?
>
> For integration with SVN tools, using the
> ROOT/{branches,tags}/$version layout is probably worthwhile. If it's a
> branch, just move it into place. -C
>

>> I did get one test failure:

[info] Test Starting: testLoadBalance(kafka.zk.ZKLoadBalanceTest)
[error] Test Failed: testLoadBalance(kafka.zk.ZKLoadBalanceTest)
junit.framework.AssertionFailedError: expected:<5> but was:<2>
[snip]
       at kafka.zk.ZKLoadBalanceTest.checkSetEqual(ZKLoadBalanceTest.scala:121)
       at kafka.zk.ZKLoadBalanceTest.testLoadBalance(ZKLoadBalanceTest.scala:89)
As Jun had mentioned earlier, we still do have some time dependent
unit tests that tend
to fail on some boxes. We want to clean it up soon.

Thanks,
Neha

On Mon, Oct 17, 2011 at 2:08 PM, Neha Narkhede <[EMAIL PROTECTED]> wrote:
>>> Why would the project be stuck with it? The repository can always berearranged, right?
>
> Yeah, that was overlooked by me while creating the branch. We thought
> that we will
> just rearrange the repo after the vote to fix the /branches/0.7 path.
>
> Thanks for the clarification Chris !
>
> -Neha
>
> On Mon, Oct 17, 2011 at 1:32 PM, Chris Douglas <[EMAIL PROTECTED]> wrote:
>> On Mon, Oct 17, 2011 at 11:39 AM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>>>> 5. Specify the NEW svn revision to be voted upon. For example,
>>>> http://svn.apache.org/repos/asf/incubator/kafka/trunk@r1181186
>>>
>>> Shouldn't 0.7 be in branches or tags?  Once the vote goes through the project will be stuck with kafka/0.7.  Is this what you guys want?
>>
>> Why would the project be stuck with it? The repository can always be
>> rearranged, right?
>>
>> For integration with SVN tools, using the
>> ROOT/{branches,tags}/$version layout is probably worthwhile. If it's a
>> branch, just move it into place. -C
>>
>

On Oct 17, 2011, at 1:32 PM, Chris Douglas wrote:

> On Mon, Oct 17, 2011 at 11:39 AM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>>> 5. Specify the NEW svn revision to be voted upon. For example,
>>> http://svn.apache.org/repos/asf/incubator/kafka/trunk@r1181186
>>
>> Shouldn't 0.7 be in branches or tags?  Once the vote goes through the project will be stuck with kafka/0.7.  Is this what you guys want?
>
> Why would the project be stuck with it? The repository can always be
> rearranged, right?

That's not my understanding but I could be wrong.  I do not agree with your reply to Neha where you state the project can rename the tag after the vote.   If a project publicly votes on a tag then the project is stuck with it.  This is something that I know many IPMC members, including Noel, feel strongly about.  Again, I could be wrong.

I'd like to take a bit of time out to point out that much of what I post is not hard gospel and I am by no means the final arbiter.  As my wife is quick to point out, I frequently recall things incorrectly.  
Regards,
Alan

On Mon, Oct 17, 2011 at 2:13 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>> Why would the project be stuck with it? The repository can always be
>> rearranged, right?
>
> That's not my understanding but I could be wrong.  I do not agree with your reply to Neha where you state the project can rename the tag after the vote.   If a project publicly votes on a tag then the project is stuck with it.  This is something that I know many IPMC members, including Noel, feel strongly about.  Again, I could be wrong.

If you couldn't rename the tag, then an RC candidate that passes a
vote would need a separate vote to give it a sane name in the
repository, or one couldn't run two concurrent votes for the same
version.

Binding a vote to a tag is elegant, presumably so the vote in the mail
archive can refer to a fixed point in the repository. It's not a
requirement, though. The MD5/signature, creating branches, creating
tags etc. are all to ensure that voters are clear about what they're
approving. Without these, it's too easy to get confused, or fail to
detect that the artifact approved by the PMC doesn't match what is
pushed to mirrors. It's good practice.

Asserting that the repository is fixed by the vote is pedantic. It's
not *good* for it to churn, but the whole purpose of "approving" a
release is for the PMC to certify that its content is property
licensed, approved by the majority of the PMC, and that it was
developed in concert with Apache's policies. A tag makes that easier
to ensure, but it's neither necessary nor sufficient. -C

On Oct 17, 2011, at 3:48 PM, Chris Douglas wrote:

> On Mon, Oct 17, 2011 at 2:13 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>>> Why would the project be stuck with it? The repository can always be
>>> rearranged, right?
>>
>> That's not my understanding but I could be wrong.  I do not agree with your reply to Neha where you state the project can rename the tag after the vote.   If a project publicly votes on a tag then the project is stuck with it.  This is something that I know many IPMC members, including Noel, feel strongly about.  Again, I could be wrong.
>
> If you couldn't rename the tag, then an RC candidate that passes a
> vote would need a separate vote to give it a sane name in the
> repository, or one couldn't run two concurrent votes for the same
> version.
>
> Binding a vote to a tag is elegant, presumably so the vote in the mail
> archive can refer to a fixed point in the repository. It's not a
> requirement, though. The MD5/signature, creating branches, creating
> tags etc. are all to ensure that voters are clear about what they're
> approving. Without these, it's too easy to get confused, or fail to
> detect that the artifact approved by the PMC doesn't match what is
> pushed to mirrors. It's good practice.
>
> Asserting that the repository is fixed by the vote is pedantic. It's
> not *good* for it to churn, but the whole purpose of "approving" a
> release is for the PMC to certify that its content is property
> licensed, approved by the majority of the PMC, and that it was
> developed in concert with Apache's policies. A tag makes that easier
> to ensure, but it's neither necessary nor sufficient. -C
A good outline about important points of a release.

However, even Neha states that the placement of the 0.7 tag was a mistake.  Fits and starts for release votes appear in most projects and especially so for podlings attempting to get their first release out.

To be frank, if there was a discussion about what to release and how to go about it before rushing to a vote, we wouldn't be at candidate 4 of this release.
Regards,
Alan

Alan,

As for the release binaries, many other Apache projects (e.g., Zookeeper,
Cassandra, Hadoop) do the same. Since everything is available after the
download, it's easy for users to try it out. We can remove the unnecessary
.class files.

As for whether to vote off trunk or a branch, most other Apache projects
vote off a branch. This may not be really needed for Kafka at this point.
However, I think it's easier to track changes, especially if we want to have
a bug fix release off 0.7. We will create the branch under /branches.

Jun

On Mon, Oct 17, 2011 at 11:39 AM, Alan D. Cabrera <[EMAIL PROTECTED]>wrote:

>
> On Oct 17, 2011, at 10:45 AM, Neha Narkhede wrote:
>
> > Hi,
> >
> > This is the fourth candidate for the first incubator release for
> > Apache Kafka, version 0.7.0-incubating.
> > There are *no* code changes since candidate 3. This candidate is
> > published to follow the updated release
> > process for Kafka.
> >
> > It fixes the following issues:
> >
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-4/RELEASE-NOTES.html
> >
> > *** Please download, test and vote by Oct, 20th, 10 am
> >
> > Note that we are voting upon the source (revision), binaries are
> > provided for convenience.
>
> Since this is a _source_ release I'm not sure there should be binaries,
> e.g. kafka-*.jar, *.class, files in the distribution.  The d/l is 50M.  Up
> to you guys.
>
> > Source and binary files:
> >
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-4/
> >
> > The SVN revision to be voted upon:
> > https://svn.apache.org/repos/asf/incubator/kafka/0.7@1185297
>
> I thought the plan was to vote off of trunk, e.g.
>
> > 5. Specify the NEW svn revision to be voted upon. For example,
> > http://svn.apache.org/repos/asf/incubator/kafka/trunk@r1181186
>
> Shouldn't 0.7 be in branches or tags?  Once the vote goes through the
> project will be stuck with kafka/0.7.  Is this what you guys want?
>
>
> Regards,
> Alan
>
>

On Oct 18, 2011, at 10:26 AM, Jun Rao wrote:

> Alan,
>
> As for the release binaries, many other Apache projects (e.g., Zookeeper,
> Cassandra, Hadoop) do the same. Since everything is available after the
> download, it's easy for users to try it out. We can remove the unnecessary
> .class files.

It's up to you guys.  I didn't see a discussion as to what the project feels should go into it and so I inquired.

> As for whether to vote off trunk or a branch, most other Apache projects
> vote off a branch. This may not be really needed for Kafka at this point.
> However, I think it's easier to track changes, especially if we want to have
> a bug fix release off 0.7. We will create the branch under /branches.

Up to you guys.  As above, I didn't see a discussion by the project as to how it wants to perform releases.  This is one of the things that the Incubator is all about, getting use to public discussion and consensus building.  As mentioned by Chris in an earlier post, it's a good idea to bind a vote to a tag; don't be afraid to trash tags until the final vote passes.  Again, it's up to you guys.
Regards,
Alan

>
> Jun
>
> On Mon, Oct 17, 2011 at 11:39 AM, Alan D. Cabrera <[EMAIL PROTECTED]>wrote:
>
>>
>> On Oct 17, 2011, at 10:45 AM, Neha Narkhede wrote:
>>
>>> Hi,
>>>
>>> This is the fourth candidate for the first incubator release for
>>> Apache Kafka, version 0.7.0-incubating.
>>> There are *no* code changes since candidate 3. This candidate is
>>> published to follow the updated release
>>> process for Kafka.
>>>
>>> It fixes the following issues:
>>>
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-4/RELEASE-NOTES.html
>>>
>>> *** Please download, test and vote by Oct, 20th, 10 am
>>>
>>> Note that we are voting upon the source (revision), binaries are
>>> provided for convenience.
>>
>> Since this is a _source_ release I'm not sure there should be binaries,
>> e.g. kafka-*.jar, *.class, files in the distribution.  The d/l is 50M.  Up
>> to you guys.
>>
>>> Source and binary files:
>>>
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-4/
>>>
>>> The SVN revision to be voted upon:
>>> https://svn.apache.org/repos/asf/incubator/kafka/0.7@1185297
>>
>> I thought the plan was to vote off of trunk, e.g.
>>
>>> 5. Specify the NEW svn revision to be voted upon. For example,
>>> http://svn.apache.org/repos/asf/incubator/kafka/trunk@r1181186
>>
>> Shouldn't 0.7 be in branches or tags?  Once the vote goes through the
>> project will be stuck with kafka/0.7.  Is this what you guys want?
>>
>>
>> Regards,
>> Alan
>>
>>

The new issue that we found seems like a blocker to me. So I am -1 on the
vote.

Jun

On Mon, Oct 17, 2011 at 10:45 AM, Neha Narkhede <[EMAIL PROTECTED]>wrote:

> Hi,
>
> This is the fourth candidate for the first incubator release for
> Apache Kafka, version 0.7.0-incubating.
> There are *no* code changes since candidate 3. This candidate is
> published to follow the updated release
> process for Kafka.
>
> It fixes the following issues:
>
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-4/RELEASE-NOTES.html
>
> *** Please download, test and vote by Oct, 20th, 10 am
>
> Note that we are voting upon the source (revision), binaries are
> provided for convenience.
>
> Source and binary files:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-4/
>
> The SVN revision to be voted upon:
> https://svn.apache.org/repos/asf/incubator/kafka/0.7@1185297
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>
> Note that the Incubator PMC needs to vote upon the release after a
> successful PPMC vote before
> any release can be made official.
>
> Thanks,
> Neha
>

And this one too - https://issues.apache.org/jira/browse/KAFKA-161

So -1, from me as well.

Thanks,
Neha
On Tue, Oct 18, 2011 at 2:52 PM, Jun Rao <[EMAIL PROTECTED]> wrote:
> The new issue is this one: https://issues.apache.org/jira/browse/KAFKA-160
>
> ---------- Forwarded message ----------
> From: Jun Rao <[EMAIL PROTECTED]>
> Date: Tue, Oct 18, 2011 at 2:52 PM
> Subject: Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 4)
> To: [EMAIL PROTECTED]
>
>
> The new issue that we found seems like a blocker to me. So I am -1 on the
> vote.
>
> Jun
>
>
> On Mon, Oct 17, 2011 at 10:45 AM, Neha Narkhede <[EMAIL PROTECTED]>wrote:
>
>> Hi,
>>
>> This is the fourth candidate for the first incubator release for
>> Apache Kafka, version 0.7.0-incubating.
>> There are *no* code changes since candidate 3. This candidate is
>> published to follow the updated release
>> process for Kafka.
>>
>> It fixes the following issues:
>>
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-4/RELEASE-NOTES.html
>>
>> *** Please download, test and vote by Oct, 20th, 10 am
>>
>> Note that we are voting upon the source (revision), binaries are
>> provided for convenience.
>>
>> Source and binary files:
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-4/
>>
>> The SVN revision to be voted upon:
>> https://svn.apache.org/repos/asf/incubator/kafka/0.7@1185297
>>
>> Kafka's KEYS file containing PGP keys we use to sign the release:
>> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>>
>> Note that the Incubator PMC needs to vote upon the release after a
>> successful PPMC vote before
>> any release can be made official.
>>
>> Thanks,
>> Neha
>>
>

Hi,

This is the fifth candidate for the first incubator release for Apache
Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
those.

It also fixes the following issues:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html

*** Please download, test and vote by Nov 3rd, 6 pm

Note that we are voting upon the source (revision), binaries are
provided for convenience.

Source and binary files:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/

The SVN revision to be voted upon:
https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721

Kafka's KEYS file containing PGP keys we use to sign the release:
http://svn.apache.org/repos/asf/incubator/kafka/KEYS

Note that the Incubator PMC needs to vote upon the release after a
successful PPMC vote before any release can be made official.

Thanks,
Neha

+1 from me. Tested quick start and embedded_consumer test in system_test.

One thing is that we should fix the quick start page
on kafka-producer-shell.sh. The server port has now changed to 9093.

Jun

On Mon, Oct 31, 2011 at 5:44 PM, Neha Narkhede <[EMAIL PROTECTED]>wrote:

> Hi,
>
> This is the fifth candidate for the first incubator release for Apache
> Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
> RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
> those.
>
> It also fixes the following issues:
>
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html
>
> *** Please download, test and vote by Nov 3rd, 6 pm
>
> Note that we are voting upon the source (revision), binaries are
> provided for convenience.
>
> Source and binary files:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/
>
> The SVN revision to be voted upon:
> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>
> Note that the Incubator PMC needs to vote upon the release after a
> successful PPMC vote before any release can be made official.
>
> Thanks,
> Neha
>

One more change to the quickstart - the consumer's message streams now
need to be parameterized, and we can add a note on consumer decoders.

Thanks,

Joel

On Wed, Nov 2, 2011 at 10:56 AM, Jun Rao <[EMAIL PROTECTED]> wrote:
> +1 from me. Tested quick start and embedded_consumer test in system_test.
>
> One thing is that we should fix the quick start page
> on kafka-producer-shell.sh. The server port has now changed to 9093.
>
> Jun
>
> On Mon, Oct 31, 2011 at 5:44 PM, Neha Narkhede <[EMAIL PROTECTED]>wrote:
>
>> Hi,
>>
>> This is the fifth candidate for the first incubator release for Apache
>> Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
>> RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
>> those.
>>
>> It also fixes the following issues:
>>
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html
>>
>> *** Please download, test and vote by Nov 3rd, 6 pm
>>
>> Note that we are voting upon the source (revision), binaries are
>> provided for convenience.
>>
>> Source and binary files:
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/
>>
>> The SVN revision to be voted upon:
>> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721
>>
>> Kafka's KEYS file containing PGP keys we use to sign the release:
>> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>>
>> Note that the Incubator PMC needs to vote upon the release after a
>> successful PPMC vote before any release can be made official.
>>
>> Thanks,
>> Neha
>>
>

I think we should revamp all the docs. There are changes to the consumer as
well, and some of the quickstart and config docs are just bad. The design
doc also needs to be updated with the new changes.

Presumably that can be done asynchronously from the release itself.

-Jay

On Wed, Nov 2, 2011 at 12:07 PM, Joel Koshy <[EMAIL PROTECTED]> wrote:

> One more change to the quickstart - the consumer's message streams now
> need to be parameterized, and we can add a note on consumer decoders.
>
> Thanks,
>
> Joel
>
> On Wed, Nov 2, 2011 at 10:56 AM, Jun Rao <[EMAIL PROTECTED]> wrote:
> > +1 from me. Tested quick start and embedded_consumer test in system_test.
> >
> > One thing is that we should fix the quick start page
> > on kafka-producer-shell.sh. The server port has now changed to 9093.
> >
> > Jun
> >
> > On Mon, Oct 31, 2011 at 5:44 PM, Neha Narkhede <[EMAIL PROTECTED]
> >wrote:
> >
> >> Hi,
> >>
> >> This is the fifth candidate for the first incubator release for Apache
> >> Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
> >> RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
> >> those.
> >>
> >> It also fixes the following issues:
> >>
> >>
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html
> >>
> >> *** Please download, test and vote by Nov 3rd, 6 pm
> >>
> >> Note that we are voting upon the source (revision), binaries are
> >> provided for convenience.
> >>
> >> Source and binary files:
> >>
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/
> >>
> >> The SVN revision to be voted upon:
> >> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721
> >>
> >> Kafka's KEYS file containing PGP keys we use to sign the release:
> >> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
> >>
> >> Note that the Incubator PMC needs to vote upon the release after a
> >> successful PPMC vote before any release can be made official.
> >>
> >> Thanks,
> >> Neha
> >>
> >
>

On Nov 2, 2011, at 12:36 PM, Jay Kreps wrote:

> I think we should revamp all the docs. There are changes to the consumer as
> well, and some of the quickstart and config docs are just bad. The design
> doc also needs to be updated with the new changes.
>
> Presumably that can be done asynchronously from the release itself.

Yep.  

I'm quite busy today but should be able to inspect the release candidate tonight.
Regards,
Alan

>
> -Jay
>
> On Wed, Nov 2, 2011 at 12:07 PM, Joel Koshy <[EMAIL PROTECTED]> wrote:
>
>> One more change to the quickstart - the consumer's message streams now
>> need to be parameterized, and we can add a note on consumer decoders.
>>
>> Thanks,
>>
>> Joel
>>
>> On Wed, Nov 2, 2011 at 10:56 AM, Jun Rao <[EMAIL PROTECTED]> wrote:
>>> +1 from me. Tested quick start and embedded_consumer test in system_test.
>>>
>>> One thing is that we should fix the quick start page
>>> on kafka-producer-shell.sh. The server port has now changed to 9093.
>>>
>>> Jun
>>>
>>> On Mon, Oct 31, 2011 at 5:44 PM, Neha Narkhede <[EMAIL PROTECTED]
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> This is the fifth candidate for the first incubator release for Apache
>>>> Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
>>>> RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
>>>> those.
>>>>
>>>> It also fixes the following issues:
>>>>
>>>>
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html
>>>>
>>>> *** Please download, test and vote by Nov 3rd, 6 pm
>>>>
>>>> Note that we are voting upon the source (revision), binaries are
>>>> provided for convenience.
>>>>
>>>> Source and binary files:
>>>>
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/
>>>>
>>>> The SVN revision to be voted upon:
>>>> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721
>>>>
>>>> Kafka's KEYS file containing PGP keys we use to sign the release:
>>>> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>>>>
>>>> Note that the Incubator PMC needs to vote upon the release after a
>>>> successful PPMC vote before any release can be made official.
>>>>
>>>> Thanks,
>>>> Neha
>>>>
>>>
>>

Zowie.  Look at all these jars that I have to make sure are kosher to distribute:

./contrib/hadoop-consumer/lib/avro-1.4.0.jar
./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
./contrib/hadoop-consumer/lib/piggybank.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-codec-1.2.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-httpclient-3.1.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-logging-1.0.4.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/joda-time-1.6.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
./contrib/hadoop-producer/lib/avro-1.4.0.jar
./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
./contrib/hadoop-producer/lib/piggybank.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/ant-1.7.1.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/ant-launcher-1.7.1.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/asm-3.2.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/avro-1.4.1.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-collections-3.2.1.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-lang-2.5.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jackson-core-asl-1.5.5.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jackson-mapper-asl-1.5.5.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jetty-6.1.22.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jetty-util-6.1.22.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/oro-2.0.8.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-2.2.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-ant-2.2.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-generator-2.2.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/qdox-1.10.1.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/servlet-api-2.5-20081211.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/slf4j-api-1.5.11.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/velocity-1.6.4.jar
./core/lib/zkclient-20110412.jar
./core/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
./core/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
./core/lib_managed/scala_2.8.0/compile/zookeeper-3.3.3.jar
./core/lib_managed/scala_2.8.0/test/cglib-nodep-2.2.jar
./core/lib_managed/scala_2.8.0/test/easymock-3.0.jar
./core/lib_managed/scala_2.8.0/test/junit-4.1.jar
./core/lib_managed/scala_2.8.0/test/objenesis-1.2.jar
./core/lib_managed/scala_2.8.0/test/scalatest-1.2.jar
./examples/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
./examples/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
./kafka-0.7.0.jar
./lib/apache-rat-0.8-SNAPSHOT.jar
./lib/sbt-launch.jar
./project/boot/scala-2.7.7/lib/scala-compiler.jar
./project/boot/scala-2.7.7/lib/scala-library.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/classpath_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compile_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-bin_2.7.7.final/compiler-interface-bin-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-bin_2.8.0.final/compiler-interface-bin-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-bin_2.8.1.final/compiler-interface-bin-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-src/compiler-interface-src-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-src/jline-0.9.94.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/control_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/io_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/ivy-2.2.0.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/ivy_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/jsch-0.1.31.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/launcher-interface-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/sbt_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/test-interface-0.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/xsbti/interface-0.7.5.jar
./project/boot/scala-2.8.0/lib/scala-compiler.jar
./project/boot/scala-2.8.0/lib/scala-library.jar
./project/plugins/lib_managed/scala_2.7.7/sbt-idea-core_2.7.7-0.1-SNAPSHOT.jar
./project/plugins/lib_managed/scala_2.7.7/sbt-idea-plugin-0.1-SNAPSHOT.jar
Can someone help me?
Regards,
Alan
On Nov 3, 2011, at 11:55 AM, Jun Rao wrote:

To Alan and Jay's point, I don't think there is a need to distribut the
./boot jars.

I thought we went over the rest in KAFKA-142, but looking back it
doesn't sound as definitive.

On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
> Zowie.  Look at all these jars that I have to make sure are kosher to distribute:
>
> ./contrib/hadoop-consumer/lib/avro-1.4.0.jar
> ./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
> ./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
> ./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
> ./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
> ./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
> ./contrib/hadoop-consumer/lib/piggybank.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-codec-1.2.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-httpclient-3.1.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-logging-1.0.4.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/joda-time-1.6.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
> ./contrib/hadoop-producer/lib/avro-1.4.0.jar
> ./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
> ./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
> ./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
> ./contrib/hadoop-producer/lib/piggybank.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/ant-1.7.1.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/ant-launcher-1.7.1.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/asm-3.2.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/avro-1.4.1.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-collections-3.2.1.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-lang-2.5.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jackson-core-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jackson-mapper-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jetty-6.1.22.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jetty-util-6.1.22.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/oro-2.0.8.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-2.2.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-ant-2.2.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-generator-2.2.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/qdox-1.10.1.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/servlet-api-2.5-20081211.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/slf4j-api-1.5.11.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/velocity-1.6.4.jar
> ./core/lib/zkclient-20110412.jar
> ./core/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
> ./core/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
> ./core/lib_managed/scala_2.8.0/compile/zookeeper-3.3.3.jar
> ./core/lib_managed/scala_2.8.0/test/cglib-nodep-2.2.jar
> ./core/lib_managed/scala_2.8.0/test/easymock-3.0.jar
> ./core/lib_managed/scala_2.8.0/test/junit-4.1.jar
> ./core/lib_managed/scala_2.8.0/test/objenesis-1.2.jar
> ./core/lib_managed/scala_2.8.0/test/scalatest-1.2.jar
> ./examples/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
> ./examples/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
> ./kafka-0.7.0.jar
> ./lib/apache-rat-0.8-SNAPSHOT.jar
> ./lib/sbt-launch.jar
> ./project/boot/scala-2.7.7/lib/scala-compiler.jar
> ./project/boot/scala-2.7.7/lib/scala-library.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/classpath_2.7.7-0.7.5.jar

On 11/03/2011 04:11 PM, Chris Burroughs wrote:
> To Alan and Jay's point, I don't think there is a need to distribut the
> ./boot jars.
>

And I think the same applies to test dependencies.

On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
> Zowie.  Look at all these jars that I have to make sure are kosher to distribute:
>
>
> Can someone help me?
>

Assuming we can cut down on the boot/test jars. All we need is a table
of "jar-name,licence", correct?

On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:

> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>> Zowie.  Look at all these jars that I have to make sure are kosher to distribute:
>>
>>
>> Can someone help me?
>>
>
> Assuming we can cut down on the boot/test jars. All we need is a table
> of "jar-name,licence", correct?

As far as the number of jars I am only concerned with regard to the size of the distribution, 50M.  That seems excessive to me and provides no real value given that the consumers of the distribution can easily build the product themselves.

With that said, yes, it would be helpful of there was a list:

jar name, license, URL that indicates the license for the jar
Regards,
Alan

In regards to the size of the distribution, wouldn't a mavenized build
help with this?

On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
>
>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>>> Zowie.  Look at all these jars that I have to make sure are kosher to distribute:
>>>
>>>
>>> Can someone help me?
>>>
>> Assuming we can cut down on the boot/test jars. All we need is a table
>> of "jar-name,licence", correct?
> As far as the number of jars I am only concerned with regard to the size of the distribution, 50M.  That seems excessive to me and provides no real value given that the consumers of the distribution can easily build the product themselves.
>
> With that said, yes, it would be helpful of there was a list:
>
> jar name, license, URL that indicates the license for the jar
>
>
> Regards,
> Alan
>

It would...

Many of the issues about distribution would automatically be solved if Maven were used.

<disclaimer>I'm a Maven zealot</disclaimer>

On Nov 4, 2011, at 8:17 AM, Mark wrote:

> In regards to the size of the distribution, wouldn't a mavenized build help with this?
>
> On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
>> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
>>
>>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>>>> Zowie.  Look at all these jars that I have to make sure are kosher to distribute:
>>>>
>>>>
>>>> Can someone help me?
>>>>
>>> Assuming we can cut down on the boot/test jars. All we need is a table
>>> of "jar-name,licence", correct?
>> As far as the number of jars I am only concerned with regard to the size of the distribution, 50M.  That seems excessive to me and provides no real value given that the consumers of the distribution can easily build the product themselves.
>>
>> With that said, yes, it would be helpful of there was a list:
>>
>> jar name, license, URL that indicates the license for the jar
>>
>>
>> Regards,
>> Alan
>>

Let me state why we included *all* the dependencies in the package
distribution. Initially I thought this distribution should just work
out-of-the-box after the download. That includes all unit tests, all
scripts in core as well as contrib. Note that the assumption was to not
have the user run ./sbt udpate to download dependencies or ./sbt package to
build the sub projects.

Now, assuming we have the user do both, here is the set of jars we can
include -

./core/lib/zkclient-20110412.jar
./lib/apache-rat-0.8-SNAPSHOT.jar
./lib/sbt-launch.jar
./contrib/hadoop-consumer/lib/avro-1.4.0.jar
./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
./contrib/hadoop-consumer/lib/piggybank.jar
./contrib/hadoop-producer/lib/avro-1.4.0.jar
./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
./contrib/hadoop-producer/lib/piggybank.jar
.*
/contrib/hadoop-consumer/target/scala_2.8.0/hadoop-consumer_2.8.0-0.7.0.jar
./contrib/hadoop-producer/target/scala_2.8.0/hadoop-producer_2.8.0-0.7.0.jar
./examples/target/scala_2.8.0/kafka-java-examples-0.7.0.jar
./core/target/scala_2.8.0/kafka-0.7.0.jar*

The jars in bold are Kafka jars. The question is how will the user be able
to run our jars, with just the stripped set of dependent jars we package ?

>> Many of the issues about distribution would automatically be solved if
Maven were used.

We use maven. All the jars in "lib_managed" are downloaded from Maven. The
question is not whether or not to use Maven. The question is whether you
have the user download dependencies build the jars themselves or not.

Once that is clear, we can reduce the set of dependent jars we include.

I would encourage everyone to give your inputs now, since this is important
to iron out for further releases.

Thanks,
Neha

On Fri, Nov 4, 2011 at 8:26 AM, Alan D. Cabrera <[EMAIL PROTECTED]>
wrote:
> It would...
>
> Many of the issues about distribution would automatically be solved if
Maven were used.
>
> <disclaimer>I'm a Maven zealot</disclaimer>
>
> On Nov 4, 2011, at 8:17 AM, Mark wrote:
>
>> In regards to the size of the distribution, wouldn't a mavenized build
help with this?
>>
>> On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
>>> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
>>>
>>>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>>>>> Zowie.  Look at all these jars that I have to make sure are kosher to
distribute:
>>>>>
>>>>>
>>>>> Can someone help me?
>>>>>
>>>> Assuming we can cut down on the boot/test jars. All we need is a table
>>>> of "jar-name,licence", correct?
>>> As far as the number of jars I am only concerned with regard to the
size of the distribution, 50M.  That seems excessive to me and provides no
real value given that the consumers of the distribution can easily build
the product themselves.
>>>
>>> With that said, yes, it would be helpful of there was a list:
>>>
>>> jar name, license, URL that indicates the license for the jar
>>>
>>>
>>> Regards,
>>> Alan
>>>
>
>

My $.02

There are different audiences for different target distributions
  - binary distribution : end user (developer) or sysadmin
  - source distribution : a developer

Therefore a binary distribution must include the dependent libraries
to make it run out of the box.

That doesn't include tests because the audience for a binary
distribution doesn't run tests.

If someone wants to run tests they are a developer and should get a
source distribution.

The source distribution should NOT contain binary dependencies. In
this case Maven or another suitable build tool should resolve any
dependencies during the build stage.

On Nov 4, 2011, at 8:51 AM, Neha Narkhede <[EMAIL PROTECTED]> wrote:

> Let me state why we included *all* the dependencies in the package
> distribution. Initially I thought this distribution should just work
> out-of-the-box after the download. That includes all unit tests, all
> scripts in core as well as contrib. Note that the assumption was to not
> have the user run ./sbt udpate to download dependencies or ./sbt package to
> build the sub projects.
>
> Now, assuming we have the user do both, here is the set of jars we can
> include -
>
> ./core/lib/zkclient-20110412.jar
> ./lib/apache-rat-0.8-SNAPSHOT.jar
> ./lib/sbt-launch.jar
> ./contrib/hadoop-consumer/lib/avro-1.4.0.jar
> ./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
> ./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
> ./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
> ./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
> ./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
> ./contrib/hadoop-consumer/lib/piggybank.jar
> ./contrib/hadoop-producer/lib/avro-1.4.0.jar
> ./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
> ./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
> ./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
> ./contrib/hadoop-producer/lib/piggybank.jar
> .*
> /contrib/hadoop-consumer/target/scala_2.8.0/hadoop-consumer_2.8.0-0.7.0.jar
> ./contrib/hadoop-producer/target/scala_2.8.0/hadoop-producer_2.8.0-0.7.0.jar
> ./examples/target/scala_2.8.0/kafka-java-examples-0.7.0.jar
> ./core/target/scala_2.8.0/kafka-0.7.0.jar*
>
> The jars in bold are Kafka jars. The question is how will the user be able
> to run our jars, with just the stripped set of dependent jars we package ?
>
>>> Many of the issues about distribution would automatically be solved if
> Maven were used.
>
> We use maven. All the jars in "lib_managed" are downloaded from Maven. The
> question is not whether or not to use Maven. The question is whether you
> have the user download dependencies build the jars themselves or not.
>
> Once that is clear, we can reduce the set of dependent jars we include.
>
> I would encourage everyone to give your inputs now, since this is important
> to iron out for further releases.
>
> Thanks,
> Neha
>
> On Fri, Nov 4, 2011 at 8:26 AM, Alan D. Cabrera <[EMAIL PROTECTED]>
> wrote:
>> It would...
>>
>> Many of the issues about distribution would automatically be solved if
> Maven were used.
>>
>> <disclaimer>I'm a Maven zealot</disclaimer>
>>
>> On Nov 4, 2011, at 8:17 AM, Mark wrote:
>>
>>> In regards to the size of the distribution, wouldn't a mavenized build
> help with this?
>>>
>>> On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
>>>> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
>>>>
>>>>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>>>>>> Zowie.  Look at all these jars that I have to make sure are kosher to
> distribute:
>>>>>>
>>>>>>
>>>>>> Can someone help me?
>>>>>>
>>>>> Assuming we can cut down on the boot/test jars. All we need is a table
>>>>> of "jar-name,licence", correct?
>>>> As far as the number of jars I am only concerned with regard to the
> size of the distribution, 50M.  That seems excessive to me and provides no
> real value given that the consumers of the distribution can easily build

> Therefore a binary distribution must include the dependent libraries
> to make it run out of the box.

I agree with Taylor here. That means our binary distribution will not
have the jars in boot/test.

>> > If someone wants to run tests they are a developer and should get a
> source distribution.

This is also a good suggestion. That means we can upload a source
distribution along with the binary distribution.

I would encourage everyone to speak up here, to avoid delaying this
release any further.

Thanks,
Neha

On Fri, Nov 4, 2011 at 9:16 AM, Taylor Gautier <[EMAIL PROTECTED]> wrote:
> My $.02
>
> There are different audiences for different target distributions
>  - binary distribution : end user (developer) or sysadmin
>  - source distribution : a developer
>
> Therefore a binary distribution must include the dependent libraries
> to make it run out of the box.
>
> That doesn't include tests because the audience for a binary
> distribution doesn't run tests.
>
> If someone wants to run tests they are a developer and should get a
> source distribution.
>
> The source distribution should NOT contain binary dependencies. In
> this case Maven or another suitable build tool should resolve any
> dependencies during the build stage.
>
>
>
> On Nov 4, 2011, at 8:51 AM, Neha Narkhede <[EMAIL PROTECTED]> wrote:
>
>> Let me state why we included *all* the dependencies in the package
>> distribution. Initially I thought this distribution should just work
>> out-of-the-box after the download. That includes all unit tests, all
>> scripts in core as well as contrib. Note that the assumption was to not
>> have the user run ./sbt udpate to download dependencies or ./sbt package to
>> build the sub projects.
>>
>> Now, assuming we have the user do both, here is the set of jars we can
>> include -
>>
>> ./core/lib/zkclient-20110412.jar
>> ./lib/apache-rat-0.8-SNAPSHOT.jar
>> ./lib/sbt-launch.jar
>> ./contrib/hadoop-consumer/lib/avro-1.4.0.jar
>> ./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
>> ./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
>> ./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
>> ./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
>> ./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
>> ./contrib/hadoop-consumer/lib/piggybank.jar
>> ./contrib/hadoop-producer/lib/avro-1.4.0.jar
>> ./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
>> ./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
>> ./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
>> ./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
>> ./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
>> ./contrib/hadoop-producer/lib/piggybank.jar
>> .*
>> /contrib/hadoop-consumer/target/scala_2.8.0/hadoop-consumer_2.8.0-0.7.0.jar
>> ./contrib/hadoop-producer/target/scala_2.8.0/hadoop-producer_2.8.0-0.7.0.jar
>> ./examples/target/scala_2.8.0/kafka-java-examples-0.7.0.jar
>> ./core/target/scala_2.8.0/kafka-0.7.0.jar*
>>
>> The jars in bold are Kafka jars. The question is how will the user be able
>> to run our jars, with just the stripped set of dependent jars we package ?
>>
>>>> Many of the issues about distribution would automatically be solved if
>> Maven were used.
>>
>> We use maven. All the jars in "lib_managed" are downloaded from Maven. The
>> question is not whether or not to use Maven. The question is whether you
>> have the user download dependencies build the jars themselves or not.
>>
>> Once that is clear, we can reduce the set of dependent jars we include.
>>
>> I would encourage everyone to give your inputs now, since this is important
>> to iron out for further releases.
>>
>> Thanks,
>> Neha
>>
>> On Fri, Nov 4, 2011 at 8:26 AM, Alan D. Cabrera <[EMAIL PROTECTED]>
>> wrote:
>>> It would...
>>>
>>> Many of the issues about distribution would automatically be solved if
>> Maven were used.
>>>
>>> <disclaimer>I'm a Maven zealot</disclaimer>
>>>
>>> On Nov 4, 2011, at 8:17 AM, Mark wrote:
>>>
>>>> In regards to the size of the distribution, wouldn't a mavenized build

Sorry, I didn't see this. I'm subscribed to kafka-dev, but not kafka-users.

As Alan has often stated, issues like these are judgement calls. Kafka
may bundle ASL-compatible jars with its release tarball. Other
projects, like Hadoop, have done this in the past. I have almost no
experience distributing or consuming Scala projects, so I can't say
anything about downstream users' expectations. Speaking generally:

In its favor, the "out of the box" experience is simpler,
configuration is trivial, one can use the software without net access,
and FAQs on handling common quirks in a user's environment are shorter
for it. Against it, the distribution is considerably larger than it
needs to be, projects depending on this one may endure more
integration hassles, and the licensing for redistribution (auditing
each jar, ensuring all attribution clauses are satisfied, etc.) is
avoidable pain. The ASF is principally about producing source code,
but if the project wants to generate and distribute a tarball with
binary artifacts then I know of no policy preventing it.

I went through the included jars and didn't see anything that couldn't
be redistributed. I also found all the licenses (included with the
jars) that were required. I think the current release can go out
as-is. I prefer source distributions and publishing to maven, but
(again) I don't know others' downstream expectations. -C

On Sat, Nov 5, 2011 at 12:04 AM, Neha Narkhede <[EMAIL PROTECTED]> wrote:
> Alan/Chris,
>
> Please can you take a look at the alternatives here and let us know
> your thoughts ?
>
> Thanks,
> Neha
>
>
> ---------- Forwarded message ----------
> From: Neha Narkhede <[EMAIL PROTECTED]>
> Date: Fri, Nov 4, 2011 at 4:20 PM
> Subject: Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
> To: [EMAIL PROTECTED]
>
>
> Alan/Chris,
>
> As the mentors/champion, I would encourage you to chime in here. We
> really want to make progress on this release. The issue found
> yesterday actually existed since the first RC. It will help to iron
> out issues all at once, instead of one RC at a time.
>
> Thanks,
> Neha
>
> On Fri, Nov 4, 2011 at 4:16 PM, Jay Kreps <[EMAIL PROTECTED]> wrote:
>> Fully agree. I don't particularly care if we have two distribution files or
>> one, but I think it is a bad user experience for the person who just wants
>> to start using our software to have to use SBT to fetch the jar files or
>> worse yet build it from source. Relying on maven to download jars doesn't
>> actually save anyone download time, it just adds more steps (you eventually
>> need the jars).
>>
>> -Jay
>>
>> On Fri, Nov 4, 2011 at 3:35 PM, Neha Narkhede <[EMAIL PROTECTED]>wrote:
>>
>>> > Therefore a binary distribution must include the dependent libraries
>>> > to make it run out of the box.
>>>
>>> I agree with Taylor here. That means our binary distribution will not
>>> have the jars in boot/test.
>>>
>>> >> > If someone wants to run tests they are a developer and should get a
>>> > source distribution.
>>>
>>> This is also a good suggestion. That means we can upload a source
>>> distribution along with the binary distribution.
>>>
>>> I would encourage everyone to speak up here, to avoid delaying this
>>> release any further.
>>>
>>> Thanks,
>>> Neha
>>>
>>> On Fri, Nov 4, 2011 at 9:16 AM, Taylor Gautier <[EMAIL PROTECTED]>
>>> wrote:
>>> > My $.02
>>> >
>>> > There are different audiences for different target distributions
>>> >  - binary distribution : end user (developer) or sysadmin
>>> >  - source distribution : a developer
>>> >
>>> > Therefore a binary distribution must include the dependent libraries
>>> > to make it run out of the box.
>>> >
>>> > That doesn't include tests because the audience for a binary
>>> > distribution doesn't run tests.
>>> >
>>> > If someone wants to run tests they are a developer and should get a
>>> > source distribution.
>>> >
>>> > The source distribution should NOT contain binary dependencies. In

I am of the same mind as Chris.  I'm not here to pass value judgments on what projects wish to put in their releases.  If I see something odd I will merely point it out and let the project decide on what to do.

On Nov 5, 2011, at 10:32 PM, Chris Douglas wrote:

> I went through the included jars and didn't see anything that couldn't
> be redistributed. I also found all the licenses (included with the
> jars) that were required. I think the current release can go out
> as-is. I prefer source distributions and publishing to maven, but
> (again) I don't know others' downstream expectations. -C

Thanks for slogging through all those jars.  If you're willing to vouch for the jars' licenses then I think things are good for a release.
Regards,
Alan

Thanks everyone for responding. Is the general consensus to let the
distribution be as is? We can always revisit publishing to Maven once that
ticket is resolved for next release.
Thanks,
Neha

On Sunday, November 6, 2011, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
> I am of the same mind as Chris.  I'm not here to pass value judgments on
what projects wish to put in their releases.  If I see something odd I will
merely point it out and let the project decide on what to do.
>
> On Nov 5, 2011, at 10:32 PM, Chris Douglas wrote:
>
>> I went through the included jars and didn't see anything that couldn't
>> be redistributed. I also found all the licenses (included with the
>> jars) that were required. I think the current release can go out
>> as-is. I prefer source distributions and publishing to maven, but
>> (again) I don't know others' downstream expectations. -C
>
> Thanks for slogging through all those jars.  If you're willing to vouch
for the jars' licenses then I think things are good for a release.
>
>
> Regards,
> Alan
>
>

Publishing to maven will be very important for users of the client
library. Since there's no separate project for that I think it is
essential, though not related to the way the daemon is distributed.

As for the daemon, it indeed seems inadequate to impose fiddling with
SBT to consumers of the daemon since some will not be using it from
scala and will have issues getting it to work.

Excited about the upcoming release!

 - pyr

On Sun, 6 Nov 2011 18:21:29 -0800
Neha Narkhede <[EMAIL PROTECTED]> wrote:

> Thanks everyone for responding. Is the general consensus to let the
> distribution be as is? We can always revisit publishing to Maven once
> that ticket is resolved for next release.
>
>
> Thanks,
> Neha
>
> On Sunday, November 6, 2011, Alan D. Cabrera <[EMAIL PROTECTED]>
> wrote:
> > I am of the same mind as Chris.  I'm not here to pass value
> > judgments on
> what projects wish to put in their releases.  If I see something odd
> I will merely point it out and let the project decide on what to do.
> >
> > On Nov 5, 2011, at 10:32 PM, Chris Douglas wrote:
> >
> >> I went through the included jars and didn't see anything that
> >> couldn't be redistributed. I also found all the licenses (included
> >> with the jars) that were required. I think the current release can
> >> go out as-is. I prefer source distributions and publishing to
> >> maven, but (again) I don't know others' downstream expectations. -C
> >
> > Thanks for slogging through all those jars.  If you're willing to
> > vouch
> for the jars' licenses then I think things are good for a release.
> >
> >
> > Regards,
> > Alan
> >
> >

Hi,
This is the sixth candidate for the first incubator release for Apache
Kafka, version 0.7.0-incubating. There were a few binary distribution
related concerns in the last RC. This candidate is published to fix those,
and include all dependent jars, except those in boot and test.

It also fixes the following issues:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/RELEASE-NOTES.html

*** Please download, test and vote by Nov 11th, noon

Note that we are voting upon the source (revision), binaries are
provided for convenience.

Source and binary files:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/

The SVN revision to be voted upon:
https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1199132

Kafka's KEYS file containing PGP keys we use to sign the release:
http://svn.apache.org/repos/asf/incubator/kafka/KEYS

Note that the Incubator PMC needs to vote upon the release after a
successful PPMC vote before any release can be made official.

Thanks,
Neha

+1 from me. Quick start works and system tests pass.

Jun

On Tue, Nov 8, 2011 at 1:23 PM, Neha Narkhede <[EMAIL PROTECTED]>wrote:

> Hi,
> This is the sixth candidate for the first incubator release for Apache
> Kafka, version 0.7.0-incubating. There were a few binary distribution
> related concerns in the last RC. This candidate is published to fix those,
> and include all dependent jars, except those in boot and test.
>
> It also fixes the following issues:
>
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/RELEASE-NOTES.html
>
> *** Please download, test and vote by Nov 11th, noon
>
> Note that we are voting upon the source (revision), binaries are
> provided for convenience.
>
> Source and binary files:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/
>
> The SVN revision to be voted upon:
> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1199132
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>
> Note that the Incubator PMC needs to vote upon the release after a
> successful PPMC vote before any release can be made official.
>
> Thanks,
> Neha
>

+1

On 11/08/2011 04:23 PM, Neha Narkhede wrote:
> Hi,
> This is the sixth candidate for the first incubator release for Apache
> Kafka, version 0.7.0-incubating. There were a few binary distribution
> related concerns in the last RC. This candidate is published to fix those,
> and include all dependent jars, except those in boot and test.
>
> It also fixes the following issues:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/RELEASE-NOTES.html
>
> *** Please download, test and vote by Nov 11th, noon
>
> Note that we are voting upon the source (revision), binaries are
> provided for convenience.
>
> Source and binary files:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/
>
> The SVN revision to be voted upon:
> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1199132
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>
> Note that the Incubator PMC needs to vote upon the release after a
> successful PPMC vote before any release can be made official.
>
> Thanks,
> Neha
>

+1

-Jay

On Tue, Nov 8, 2011 at 1:23 PM, Neha Narkhede <[EMAIL PROTECTED]>wrote:

> Hi,
> This is the sixth candidate for the first incubator release for Apache
> Kafka, version 0.7.0-incubating. There were a few binary distribution
> related concerns in the last RC. This candidate is published to fix those,
> and include all dependent jars, except those in boot and test.
>
> It also fixes the following issues:
>
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/RELEASE-NOTES.html
>
> *** Please download, test and vote by Nov 11th, noon
>
> Note that we are voting upon the source (revision), binaries are
> provided for convenience.
>
> Source and binary files:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/
>
> The SVN revision to be voted upon:
> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1199132
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>
> Note that the Incubator PMC needs to vote upon the release after a
> successful PPMC vote before any release can be made official.
>
> Thanks,
> Neha
>

- artifact has been properly signed
- I have confirmed that all the jars that are included the distribution are AL 2.0 compatible

+1
On Nov 8, 2011, at 1:23 PM, Neha Narkhede wrote:

> Hi,
> This is the sixth candidate for the first incubator release for Apache
> Kafka, version 0.7.0-incubating. There were a few binary distribution
> related concerns in the last RC. This candidate is published to fix those,
> and include all dependent jars, except those in boot and test.
>
> It also fixes the following issues:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/RELEASE-NOTES.html
>
> *** Please download, test and vote by Nov 11th, noon
>
> Note that we are voting upon the source (revision), binaries are
> provided for convenience.
>
> Source and binary files:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/
>
> The SVN revision to be voted upon:
> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1199132
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>
> Note that the Incubator PMC needs to vote upon the release after a
> successful PPMC vote before any release can be made official.
>
> Thanks,
> Neha

I ran test in sbt and I get compilation errors.  Does that matter to you guys?
Regards,
Alan

On Nov 8, 2011, at 1:23 PM, Neha Narkhede wrote:

> Hi,
> This is the sixth candidate for the first incubator release for Apache
> Kafka, version 0.7.0-incubating. There were a few binary distribution
> related concerns in the last RC. This candidate is published to fix those,
> and include all dependent jars, except those in boot and test.
>
> It also fixes the following issues:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/RELEASE-NOTES.html
>
> *** Please download, test and vote by Nov 11th, noon
>
> Note that we are voting upon the source (revision), binaries are
> provided for convenience.
>
> Source and binary files:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/
>
> The SVN revision to be voted upon:
> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1199132
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>
> Note that the Incubator PMC needs to vote upon the release after a
> successful PPMC vote before any release can be made official.
>
> Thanks,
> Neha

Never mind.  Did a packages and re-ran tests and everything's fine.
Regards,
Alan

On Nov 11, 2011, at 8:18 AM, Alan D. Cabrera wrote:

> I ran test in sbt and I get compilation errors.  Does that matter to you guys?
>
>
> Regards,
> Alan
>
> On Nov 8, 2011, at 1:23 PM, Neha Narkhede wrote:
>
>> Hi,
>> This is the sixth candidate for the first incubator release for Apache
>> Kafka, version 0.7.0-incubating. There were a few binary distribution
>> related concerns in the last RC. This candidate is published to fix those,
>> and include all dependent jars, except those in boot and test.
>>
>> It also fixes the following issues:
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/RELEASE-NOTES.html
>>
>> *** Please download, test and vote by Nov 11th, noon
>>
>> Note that we are voting upon the source (revision), binaries are
>> provided for convenience.
>>
>> Source and binary files:
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/
>>
>> The SVN revision to be voted upon:
>> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1199132
>>
>> Kafka's KEYS file containing PGP keys we use to sign the release:
>> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>>
>> Note that the Incubator PMC needs to vote upon the release after a
>> successful PPMC vote before any release can be made official.
>>
>> Thanks,
>> Neha
>

I also ran a mirroring test and an audit.

+1

(Although, I'm past the 12pm deadline.)

Thanks,

Joel
On Tue, Nov 8, 2011 at 1:23 PM, Neha Narkhede <[EMAIL PROTECTED]> wrote:
> Hi,
> This is the sixth candidate for the first incubator release for Apache
> Kafka, version 0.7.0-incubating. There were a few binary distribution
> related concerns in the last RC. This candidate is published to fix those,
> and include all dependent jars, except those in boot and test.
>
> It also fixes the following issues:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/RELEASE-NOTES.html
>
> *** Please download, test and vote by Nov 11th, noon
>
> Note that we are voting upon the source (revision), binaries are
> provided for convenience.
>
> Source and binary files:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/
>
> The SVN revision to be voted upon:
> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1199132
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>
> Note that the Incubator PMC needs to vote upon the release after a
> successful PPMC vote before any release can be made official.
>
> Thanks,
> Neha
>

:) There's no such think as voting deadlines but, with that said, should we not conclude this vote?
Regards,
Alan

On Nov 11, 2011, at 1:04 PM, Joel Koshy wrote:

> I also ran a mirroring test and an audit.
>
> +1
>
> (Although, I'm past the 12pm deadline.)
>
> Thanks,
>
> Joel
>
>
> On Tue, Nov 8, 2011 at 1:23 PM, Neha Narkhede <[EMAIL PROTECTED]> wrote:
>> Hi,
>> This is the sixth candidate for the first incubator release for Apache
>> Kafka, version 0.7.0-incubating. There were a few binary distribution
>> related concerns in the last RC. This candidate is published to fix those,
>> and include all dependent jars, except those in boot and test.
>>
>> It also fixes the following issues:
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/RELEASE-NOTES.html
>>
>> *** Please download, test and vote by Nov 11th, noon
>>
>> Note that we are voting upon the source (revision), binaries are
>> provided for convenience.
>>
>> Source and binary files:
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/
>>
>> The SVN revision to be voted upon:
>> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1199132
>>
>> Kafka's KEYS file containing PGP keys we use to sign the release:
>> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>>
>> Note that the Incubator PMC needs to vote upon the release after a
>> successful PPMC vote before any release can be made official.
>>
>> Thanks,
>> Neha
>>

+1

Checksum and signature match, tests all passed. Assuming no included
jars changed between RC5 and RC6, the licensing appears to be in
order, too. -C

On Tue, Nov 8, 2011 at 1:23 PM, Neha Narkhede <[EMAIL PROTECTED]> wrote:
> Hi,
> This is the sixth candidate for the first incubator release for Apache
> Kafka, version 0.7.0-incubating. There were a few binary distribution
> related concerns in the last RC. This candidate is published to fix those,
> and include all dependent jars, except those in boot and test.
>
> It also fixes the following issues:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/RELEASE-NOTES.html
>
> *** Please download, test and vote by Nov 11th, noon
>
> Note that we are voting upon the source (revision), binaries are
> provided for convenience.
>
> Source and binary files:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-6/
>
> The SVN revision to be voted upon:
> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1199132
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>
> Note that the Incubator PMC needs to vote upon the release after a
> successful PPMC vote before any release can be made official.
>
> Thanks,
> Neha
>

Hi,

This is the eigth candidate for the first incubator release for Apache
Kafka, version 0.7.0-incubating. Based on the feedback from the
general incubator list
(http://markmail.org/message/bkkfwjexr7ixmh5b?q=Feedback+kafka+0%2E7%2E0+list:org%2Eapache%2Eincubator%2Egeneral),
the only changes from the last candidate are the NOTICE and LICENSE files.

It also fixes the following issues:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-8/RELEASE-NOTES.html

*** Please download, test and vote by Dec 19th, 11 am

Note that we are voting upon the source tag.

Release artifacts:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-8/

The SVN tag to be voted upon:
https://svn.apache.org/repos/asf/incubator/kafka/tags/kafka-0.7.0-incubating-candidate-8

Kafka's KEYS file containing PGP keys we use to sign the release:
http://svn.apache.org/repos/asf/incubator/kafka/KEYS

Note that the Incubator PMC needs to vote upon the release after a
successful PPMC vote before
any release can be made official.

Thanks,
Neha