It was suggested on general@ that a source only release reduces the
number of requirements with regards to dealing with (transitive)
dependencies and NOTICE files [1].  I can't recall if this is new or not
but the release guide also currently suggests them for early projects [2].

My reading is that since we would only be distributing source code, the
NOTICE file should not reflect binary dependencies and would have *only*
the standard Apache bit [3].  Same for LICENSE.

Now it is (much) more convenient for users to have a nice binary
tarball.  And better for client writers to have binary releases that can
be re-packaged downstream, live in maven repositories etc. However, I
think at this point it is more important for the community to have a
common reference point now (aka a release) than a binary release later.
 I strongly suspect that there is currently a splintering among pre-ASF
releases, trunk, and the various 0.7 RCs.  This is not healthy for the
community.

I'm willing to slog through the dependencies, and if I need to write
code to do that (which seems like the only reasonable option to me), so
be it.  But I don't think we need to block everything on that unless we
want to.

[1]
http://mail-archives.apache.org/mod_mbox/incubator-kafka-dev/201112.mbox/%3CCAKTa1mhb%3DKMym9KOFDtXZHtoaMwky0Vcv-%2Bm4vB%2BR9%2BwND1PnA%40mail.gmail.com%3E

[2]
http://incubator.apache.org/guides/releasemanagement.html#notes-on-source-only-releases

[3] http://www.apache.org/legal/src-headers.html#notice

On 12/03/2011 02:40 PM, Chris Burroughs wrote:
> My reading is that since we would only be distributing source code, the
> NOTICE file should not reflect binary dependencies and would have *only*
> the standard Apache bit [3].  Same for LICENSE.

I suppose any jar's checked into svn would complicate this a bit.
Perhaps it would also be best to exclude them, or just exclude contrib
where most of them seem to be.

Chris,

Thanks for stepping up to help here. Based on feedback from various members
on general@, I think it is wiser to do the source release, with the README
having a "How to build and download dependencies" section.

We still have to go through all the jars we package in our source release,
and right now we have about 17 of those. To reduce this overhead, I worked
on KAFKA-222. I would encourage everyone to review this JIRA closely -
https://issues.apache.org/jira/browse/KAFKA-222

Since the build file for the contrib module has changed, can people who use
hadoop-consumer and hadoop-producer help test it out ?

Thanks,
Neha

On Sat, Dec 3, 2011 at 11:54 AM, Chris Burroughs
<[EMAIL PROTECTED]>wrote:

> On 12/03/2011 02:40 PM, Chris Burroughs wrote:
> > My reading is that since we would only be distributing source code, the
> > NOTICE file should not reflect binary dependencies and would have *only*
> > the standard Apache bit [3].  Same for LICENSE.
>
> I suppose any jar's checked into svn would complicate this a bit.
> Perhaps it would also be best to exclude them, or just exclude contrib
> where most of them seem to be.
>

If you go this way, you're still left with two issues if you want
adoption to be smooth:

* KAFKA-133 which makes integrating clients hard otherwise
* Maybe building recipes for creating standard packages (rpm + deb)

Most people will install and configure kafka from a CM system (puppet,
chef or pallet) but it would still make life much easier if there were
packages. I suppose this would require the LICENSE thing to be clear
though.

FWIW i think the way cassandra handles this is very convenient (with a
separate package repository which holds releases) but only having debian
rules could already help a bit.

Now that being said, given the time the release has dragged on, I think
if a source only release speeds things up, it's for the best.

  - pyr

On Sun, Dec 04, 2011 at 08:52:45PM -0800, Neha Narkhede wrote:
> Chris,
>
> Thanks for stepping up to help here. Based on feedback from various members
> on general@, I think it is wiser to do the source release, with the README
> having a "How to build and download dependencies" section.
>
> We still have to go through all the jars we package in our source release,
> and right now we have about 17 of those. To reduce this overhead, I worked
> on KAFKA-222. I would encourage everyone to review this JIRA closely -
> https://issues.apache.org/jira/browse/KAFKA-222
>
> Since the build file for the contrib module has changed, can people who use
> hadoop-consumer and hadoop-producer help test it out ?
>
> Thanks,
> Neha
>
> On Sat, Dec 3, 2011 at 11:54 AM, Chris Burroughs
> <[EMAIL PROTECTED]>wrote:
>
> > On 12/03/2011 02:40 PM, Chris Burroughs wrote:
> > > My reading is that since we would only be distributing source code, the
> > > NOTICE file should not reflect binary dependencies and would have *only*
> > > the standard Apache bit [3].  Same for LICENSE.
> >
> > I suppose any jar's checked into svn would complicate this a bit.
> > Perhaps it would also be best to exclude them, or just exclude contrib
> > where most of them seem to be.
> >