Just to clarify - this code should still be built and bundled with Flume. What I am proposing is to reorganize the code, so that they are in separate modules - thus in different folders. These contributions should still be of the same quality we expect and also be built in the main flume build.
Thanks Hari On Sat, Jun 16, 2012 at 6:32 PM, Hari Shreedharan <[email protected] > wrote: > Hi Flume devs, > > I would like to propose moving several pieces of code out to a different > contrib module which are pieces of code not essential to flume > functionality but pluggable into some Flume framework. Examples of this are > the various kinds of interceptors, event serializers etc. I don't think we > should keep them in the code tree as the interceptor framework or the > HBase/HDFS sinks - as this adds several files into the main module. When > recently a new serializer was being contributed for the HbaseSink, I really > wanted it checked in, and I checked it into the main module - since I > didn't know where else it should go. It didn't make much sense to create a > new package either. > > It is really great that people are implementing features and contributing > it back to Flume. This is an example of Flume maturing as a project. As a > result, we need to define a place where such contributions go. We could > keep them in the same package to prevent bc issues, but move them out to > another module. > > What do you guys think? > > > Thanks! > Hari >
