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

Switch to Threaded View
Hadoop >> mail # general >> Plans for the 0.22 Release

Copy link to this message
Re: Plans for the 0.22 Release
[Sending this again as my original post didn't make it to the list for
some reason. Can't see it in the moderation queue either.]

I don't personally see HADOOP-6685 as a blocker for a 0.22 release,
since there is a lot of value in there already that has not been
released yet, such as security. However, to get HADOOP-6685 resolved,
from my point of view the main thing to sort out are the modularity
concerns that I and others have raised, so that serializations are
pluggable and don't add potentially incompatible libraries onto the
user's classpath.


On Mon, Dec 20, 2010 at 11:39 AM, Konstantin Shvachko
> My question is
>    What would be an *ACCEPTABLE *resolution of HADOOP-6685 for *YOU *to
> move *0.22* forward?
> Asking Owen as the author of the patch, Doug and Tom as they vetoed it.
> If I am asking the wrong question please let me know.
> I am not proposing a particular solution, just trying to understand
> 1. if there is any
> 2. What is it if there is.
> If, say removing dependency for Avro and updating the patch symmetrically
> removing PB dependency is a solution, if there is a solution to SequenceFile
> and byte array issues, then lets do it.
> If not then lets face it.
> Thanks,
> --Konstantin
> On Sun, Dec 19, 2010 at 11:27 PM, Owen O'Malley <[EMAIL PROTECTED]> wrote:
>> On Fri, Dec 17, 2010 at 2:52 PM, Doug Cutting <[EMAIL PROTECTED]> wrote:
>> > On 12/17/2010 02:34 PM, Konstantin Shvachko wrote:
>> >
>> >> It could be a zero-option plan - remove dependencies both for Avro and
>> >> ProtocolBuffers out into libraries, similar to schedulers.
>> >>
>> >
>> > I'd be fine with removing Avro from the mapreduce user's classpath. It's
>> > currently an unused option for RPC, and is used server-side on the
>> > jobtracker.  It could be removed from the user classpath today without
>> loss
>> > of critical functionality.
>> That would be non-trivial and no one has requested that. You haven't
>> answered Konstantin's question.
>> What do you consider the technical reasons for rejecting the patch as is?
>> -- Owen