Hey Arun, I put up patches for the QJM backport merge yesterday. Aaron said he'd take a look at reviewing them, so I anticipate that to be finished "real soon now". Sorry for the delay.
-Todd On Tue, Dec 4, 2012 at 6:09 AM, Arun C Murthy <a...@hortonworks.com> wrote: > Lohit, > > There are some outstanding blockers and I'm still awaiting the QJM merge. > > Feel free to watch the blocker list: > http://s.apache.org/e1J > > Arun > > On Dec 3, 2012, at 10:02 AM, lohit wrote: > >> Hello Hadoop Release managers, >> Any update on this? >> >> Thanks, >> Lohit >> >> 2012/11/20 Tom White <t...@cloudera.com> >> >>> On Mon, Nov 19, 2012 at 6:09 PM, Siddharth Seth >>> <seth.siddha...@gmail.com> wrote: >>>> YARN-142/MAPREDUCE-4067 should ideally be fixed before we commit to API >>>> backward compatibility. Also, from the recent YARN meetup - there seemed >>> to >>>> be a requirement to change the AM-RM protocol for container requests. In >>>> this case, I believe it's OK to not have all functionality implemented, >>> as >>>> long as the protocol itself can represent the requirements. >>> >>> I agree. Do you think we can make these changes before removing the >>> 'alpha' label, i.e. in 2.0.3? If that's not possible for the container >>> requests change, then we could mark AMRMProtocol (or related classes) >>> as @Evolving. Another alternative would be to introduce a new >>> interface. >>> >>>> However, as >>>> Bobby pointed out, given the current adoption by other projects - >>>> incompatible changes at this point can be problematic and needs to be >>>> figured out. >>> >>> We have a mechanism for this already. If something is marked as >>> @Evolving it can change incompatibly between minor versions - e.g. >>> 2.0.x to 2.1.0. If it is @Stable then it can only change on major >>> versions, e.g. 2.x.y to 3.0.0. Let's make sure we are happy with the >>> annotations - and willing to support them at the indicated level - >>> before we remove the 'alpha' label. Of course, we strive not to change >>> APIs without a very good reason, but if we do we should do so within >>> the guidelines so that users know what to expect. >>> >>> Cheers, >>> Tom >>> >>>> >>>> Thanks >>>> - Sid >>>> >>>> >>>> On Mon, Nov 19, 2012 at 8:22 AM, Robert Evans <ev...@yahoo-inc.com> >>> wrote: >>>> >>>>> I am OK with removing the alpha assuming that we think that the APIs are >>>>> stable enough that we are willing to truly start maintaining backwards >>>>> compatibility on them within 2.X. From what I have seen I think that >>> they >>>>> are fairly stable and I think there is enough adoption by other projects >>>>> right now that breaking backwards compatibility would be problematic. >>>>> >>>>> --Bobby Evans >>>>> >>>>> On 11/16/12 11:34 PM, "Stack" <st...@duboce.net> wrote: >>>>> >>>>>> On Fri, Nov 16, 2012 at 3:38 PM, Aaron T. Myers <a...@cloudera.com> >>> wrote: >>>>>>> Hi Arun, >>>>>>> >>>>>>> Given that the 2.0.3 release is intended to reflect the growing >>>>>>> stability >>>>>>> of YARN, and the QJM work will be included in 2.0.3 which provides a >>>>>>> complete HDFS HA solution, I think it's time we consider removing the >>>>>>> "-alpha" label from the release version. My preference would be to >>>>>>> remove >>>>>>> the label entirely, but we could also perhaps call it "-beta" or >>>>>>> something. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>> >>>>>> I think it fine after two minor releases undoing the '-alpha' suffix. >>>>>> >>>>>> If folks insist we next go to '-beta', I'd hope we'd travel all >>>>>> remaining 22 letters of the greek alphabet before we 2.0.x. >>>>>> >>>>>> St.Ack >>>>> >>>>> >>> >> >> >> >> -- >> Have a Nice Day! >> Lohit > > -- > Arun C. Murthy > Hortonworks Inc. > http://hortonworks.com/ > > -- Todd Lipcon Software Engineer, Cloudera
