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
See inline.

On 12/01/2013 05:31 PM, Juhani Connolly wrote:
> 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.
Why cannot we just remove it when no one cares about it? If the
community does not care enough to maintain it, there is no reason to
keep it.
If it is in trunk then it has not been released yet and it is fair game.
I would not see any issue removing any part that is not in a releasable
state and no one willing to maintain such part before a release. From my
point of view, if it is in trunk and not released, then it can be
completely changed or even dropped at any time.
If it is part of a release then keeping it for bug fix releases should
not really matter since a status quo should be achievable without much
troubles since Apache Flume APIs should remain stable. And since we are
talking about bug fixes, there is no reasons to change anything in it
besides bug fixes contributed by interested parties (commiters or not).

And why must there be another equivalent component before we can
deprecate one?
Is such policy stated anywhere?
If people care that much about such component then someone will
volunteer to help maintain it. Otherwise the community is not that much
interested in it.

In any case the code will not be lost. Anyone will be one git/svn
command away from bringing it back.
>> 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.
Provided we do not hesitate to remove unmaintained components sometimes,
this would be a non issue. This would enable us to openly accept
interested community members while taking out unmaintained code.
Otherwise I would agree with your concerns.

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