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
