[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 >> >
