Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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.

Thanks,
Tom

On Mon, Dec 20, 2010 at 11:39 AM, Konstantin Shvachko
<[EMAIL PROTECTED]> 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 <[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
>>
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB