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 > <chris.burrou...@gmail.com>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. > >
