Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Flume, mail # dev - Regarding the adding of additional sinks/sources for various DB's

Copy link to this message
Re: Regarding the adding of additional sinks/sources for various DB's
Juhani Connolly 2013-12-02, 01:31
Commenting inline

On 11/30/2013 09:03 AM, Bruno Mahé wrote:
> If a component gets developed outside of Apache, what is the cost to
> integrate it? How would that work? I assume one would have to go
> through a code grant. If so, would a developer have to go track all
> past contributors to agree on the code grant terms? Or should a CLA be
> prepared in case of such event?
> Why is it bad to get a new source/sink for the new, fancy, FooBrBaz
> data store? What if it does take off? I would contend that the success
> of that data store does not matter as long as there is a community
> interested in it.
> And why is it so costly to include it when it is so cheap to remove it
> when no one cares about it anymore?
We can't just "remove it when no one cares about it". If it goes into
the main trunk, we're committing to providing the feature, at least
until a major version change, and even then it would generally only be
phased out if it gets deprecated by another equivalent component.
> Including people from the outer layers also increases the chances of
> getting them interested in the core of Apache Flume. They will most
> likely notice something to improve somewhere else and start helping in
> core parts. Even more so if they are going through all the steps to
> get their code in Apache Flume.
I agree with this, and it's the strongest argument for putting new stuff
in. Of course if these people just contribute their component and then
leave it for others to maintain, things get more difficult.
> Imho, the cost on passing on possible contributors is quite high
> comparing to deleting unmaintained parts. Not just for the core Apache
> Flume developers, but for the users in general as well.
> Thanks,
> Bruno