hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom White <tom.e.wh...@gmail.com>
Subject Re: Plans for the 0.22 Release
Date Mon, 20 Dec 2010 20:12:13 GMT
[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
<shv.hadoop@gmail.com> wrote:
> 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 <omalley@apache.org> wrote:
>> On Fri, Dec 17, 2010 at 2:52 PM, Doug Cutting <cutting@apache.org> 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

View raw message