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

Switch to Threaded View
Flume, mail # dev - [DISCUSS] Feature bloat and contrib module


Copy link to this message
-
Re: [DISCUSS] Feature bloat and contrib module
Ashish 2013-12-18, 16:46
I am with you for most discussion, but on two points, we differ a bit

- Easy In - Easy Out, would be a bit difficult to achieve. Easy in is easy,
but on what basis we move a component out. Someone not maintaining it or
someone not using it. Would be difficult for us to know. Probably there may
be easy way of doing this, BigTop deals with these cases more often than me.

- Committers are facilitators agree, but we do need to review the
contributions, else the whole process would break.

>From the discussion it seems that nobody seems to be inclined towards
contrib. How about giving components place under sources/sinks/interceptors
modules which are already present. Most of the times, only these would be
the things that would come in. These components maintain compatibility with
Flume's current version, get released alongside. Extra burden for core
Dev's for sure, but would save a lot of trouble for Users. Final call will
still be with Flume Dev's

@Bruno - Buddy Please do not stop work on Redis component. This is the last
thing we want. I am not a Committer here, but definitely willing to pitch
in for review and testing it a bit (would learn redis as well :) )

cheers
ashish

On Tue, Dec 17, 2013 at 1:04 PM, Bruno Mahé <[EMAIL PROTECTED]> wrote:

> I will probably end up repeating the very same thing than the other
> discussion.
>
>
>
> Summarizing my suggestions:
> * Commiters are not the sole developers. There is no reason for commiters
> to take all these responsibilities on their shoulders. Also developer !> commiter.
> * Easy IN, Easy OUT. If no one volunteers to maintain something, then
> there is no reason to keep it since the community is not interested in it
> anyway.
> * Easy to get in means more contributions and more contributors. Also a
> way to grow community and have contributors becoming full commiters. It is
> more than likely they will notice things that can be improved elsewhere and
> start being more active overall.
> * Easy to get out means only the maintained stuff stays. Stuff would most
> likely get kicked out before a feature release (ex: 1.5 vs 1.6). Bug fix
> releases have no reason to kick out components since they are unlikely to
> break in between bug fix releases (ex: 1.5.2 vs 1.5.3).
> * Spreading sources and sinks is going to be quite hard on users. This
> would means users would have to be developers themselves since they would
> have to:
>     - Find the source/sink on some random repository which may or may not
> be maintained. Pick one of the repository out of all the ones the user has
> found
>     - Build it against their own version of Apache Flume (Apache, CDH,
> PHD, HDP...)
>     - Resolve dependencies and build issues between their version of
> Apache Flume and source/sink since the source/sink may or may not have been
> maintained
>     - Qualify the integration between their version of Apache Flume and
> source/sink
> * Spreading sources and sinks is going to be quite hard on developers. Why
> should I target Apache Flume when I can just target my version of Flume
> (CDH, PHD, HDP) ?
> * Spreading sources and sinks is going to be quite hard on integrators
> such as Apache Bigtop. This would means working with as many people as
> there are source/sinks. Each own with their own way of working and
> schedules.
>
>
> For the details, see inline.
>
>
>
> On 12/16/2013 09:17 PM, Ashish wrote:
>
>> @Israel - IMHO JIRA is not a good use-case for these discussion.
>> The discussion can easily be tracked on flume.markmail.com and the link
>> is
>> provided
>>
>>
>> On Tue, Dec 17, 2013 at 7:19 AM, Mike Percy <[EMAIL PROTECTED]> wrote:
>>
>>  I have created a JIRA Brainstorming task to track this.
>>>>
>>>
>>> Hmm, I think there is a risk of losing this discussion in the flood of
>>> JIRA
>>> traffic due to email filters. So I'm going to respond here on this
>>> thread.
>>> If you want to reference this thread in the future, you can use this URL:
>>> http://markmail.org/message/7x7tewbxqw4ubjyp
thanks
ashish

Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal