Re: [DISCUSS] Flume 1.4 release plan

[Roshan Naik <ro...@hortonworks.com>]

shall i go ahead and file a jira on dropping the Recoverable Memory Channel
from 1.4  ?


On Wed, May 29, 2013 at 3:36 PM, Roshan Naik <ro...@hortonworks.com> wrote:

> Perhaps this is a good point to consider dropping the Recoverable Memory
> Channel from  1.4 ... since it has been deprecated.
>
>
> On Wed, May 29, 2013 at 8:49 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> I don't consider this a showstopper, but it should be a learning
>> experience. First, Flume should probably release more often. Second, where
>> possible deprecate stuff in one release and delete it in the next.
>>
>>
>> Ralph
>>
>> On May 28, 2013, at 6:47 AM, Mike Percy wrote:
>>
>> > Hmm, I wish we had agreed on the use of those APIs outside the project
>> up
>> > front. The interfaces log4j2 used to embed Flume were not designed to be
>> > public. Now that we have a stable API, hopefully log4j2 can have another
>> > release soon which takes advantage of the embedded agent APIs.
>> >
>> > AFAICT it's not going to be straightforward to provide backward
>> > compatibility with the previous APIs, but I'm willing to be proven
>> wrong...
>> >
>> > Regards,
>> > Mike
>> >
>> >
>> >
>> > On Sun, May 26, 2013 at 7:58 AM, Ralph Goers <
>> ralph.goers@dslextreme.com>wrote:
>> >
>> >> The one concern I have is that when adding support for embedded agents
>> >> some classes were removed. This means if users of Log4j 2 try to use
>> 1.4
>> >> they will have problems until it is modified to use Flume 1.4.  It
>> would
>> >> have been nice to have had at least one release where both were
>> present.
>> >>
>> >> Ralph
>> >>
>> >> On May 22, 2013, at 12:33 AM, Mike Percy wrote:
>> >>
>> >>> Hi folks,
>> >>> We have had over 100 commits since 1.3.1, and a bunch of new features
>> and
>> >>> improvements including a Thrift source, much improved ElasticSearch
>> sink,
>> >>> support for a new plugins directory and layout, compression support in
>> >> the
>> >>> avro sink/source, improved checkpointing in the file channel and more,
>> >> plus
>> >>> a lot of bug fixes.
>> >>>
>> >>> It seems to me that it's time to start thinking about cutting a 1.4
>> >>> release. I would be happy to volunteer to RM the release. Worth noting
>> >> that
>> >>> I will be unavailable for the next two weeks... but after that I'd be
>> >> happy
>> >>> to pick this up and run with it. That's also a decent amount of time
>> for
>> >>> people  to get moving on patches and reviews for their favorite
>> features,
>> >>> bug fixes, etc.
>> >>>
>> >>> If this all sounds OK, I'd like to suggest targeting the last week of
>> >> June
>> >>> as a release date. If we can release in time for Hadoop Summit then
>> that
>> >>> would be pretty nice. Otherwise, if something comes up and we can't
>> get
>> >> the
>> >>> release out that week, let's shoot for the first week of July at the
>> >> latest.
>> >>>
>> >>> Please let me know your thoughts.
>> >>>
>> >>> Regards,
>> >>> Mike
>> >>
>> >>
>>
>>
>

Re: [DISCUSS] Flume 1.4 release plan

[Mike Percy <mp...@apache.org>]

Hi Roshan,
I'm OK with that if no one else has any concerns.

I'll start a separate thread with a scoping discussion.

Thanks,
Mike


On Thu, Jun 6, 2013 at 11:29 AM, Roshan Naik <ro...@hortonworks.com> wrote:

> shall i go ahead and file a jira on dropping the Recoverable Memory Channel
> from 1.4  ?
>
>
> On Wed, May 29, 2013 at 3:36 PM, Roshan Naik <ro...@hortonworks.com>
> wrote:
>
> > Perhaps this is a good point to consider dropping the Recoverable Memory
> > Channel from  1.4 ... since it has been deprecated.
> >
> >
> > On Wed, May 29, 2013 at 8:49 AM, Ralph Goers <ralph.goers@dslextreme.com
> >wrote:
> >
> >> I don't consider this a showstopper, but it should be a learning
> >> experience. First, Flume should probably release more often. Second,
> where
> >> possible deprecate stuff in one release and delete it in the next.
> >>
> >>
> >> Ralph
> >>
> >> On May 28, 2013, at 6:47 AM, Mike Percy wrote:
> >>
> >> > Hmm, I wish we had agreed on the use of those APIs outside the project
> >> up
> >> > front. The interfaces log4j2 used to embed Flume were not designed to
> be
> >> > public. Now that we have a stable API, hopefully log4j2 can have
> another
> >> > release soon which takes advantage of the embedded agent APIs.
> >> >
> >> > AFAICT it's not going to be straightforward to provide backward
> >> > compatibility with the previous APIs, but I'm willing to be proven
> >> wrong...
> >> >
> >> > Regards,
> >> > Mike
> >> >
> >> >
> >> >
> >> > On Sun, May 26, 2013 at 7:58 AM, Ralph Goers <
> >> ralph.goers@dslextreme.com>wrote:
> >> >
> >> >> The one concern I have is that when adding support for embedded
> agents
> >> >> some classes were removed. This means if users of Log4j 2 try to use
> >> 1.4
> >> >> they will have problems until it is modified to use Flume 1.4.  It
> >> would
> >> >> have been nice to have had at least one release where both were
> >> present.
> >> >>
> >> >> Ralph
> >> >>
> >> >> On May 22, 2013, at 12:33 AM, Mike Percy wrote:
> >> >>
> >> >>> Hi folks,
> >> >>> We have had over 100 commits since 1.3.1, and a bunch of new
> features
> >> and
> >> >>> improvements including a Thrift source, much improved ElasticSearch
> >> sink,
> >> >>> support for a new plugins directory and layout, compression support
> in
> >> >> the
> >> >>> avro sink/source, improved checkpointing in the file channel and
> more,
> >> >> plus
> >> >>> a lot of bug fixes.
> >> >>>
> >> >>> It seems to me that it's time to start thinking about cutting a 1.4
> >> >>> release. I would be happy to volunteer to RM the release. Worth
> noting
> >> >> that
> >> >>> I will be unavailable for the next two weeks... but after that I'd
> be
> >> >> happy
> >> >>> to pick this up and run with it. That's also a decent amount of time
> >> for
> >> >>> people  to get moving on patches and reviews for their favorite
> >> features,
> >> >>> bug fixes, etc.
> >> >>>
> >> >>> If this all sounds OK, I'd like to suggest targeting the last week
> of
> >> >> June
> >> >>> as a release date. If we can release in time for Hadoop Summit then
> >> that
> >> >>> would be pretty nice. Otherwise, if something comes up and we can't
> >> get
> >> >> the
> >> >>> release out that week, let's shoot for the first week of July at the
> >> >> latest.
> >> >>>
> >> >>> Please let me know your thoughts.
> >> >>>
> >> >>> Regards,
> >> >>> Mike
> >> >>
> >> >>
> >>
> >>
> >
>