OK, QJM is now in branch-2. I also merged all the follow-up patches I could find so that branch-2 and trunk should be equivalent with regard to QJM functionality at this point. If anyone sees anything I missed, feel free to give me a holler.
Thanks Todd On Tue, Dec 4, 2012 at 6:56 PM, Arun Murthy <a...@hortonworks.com> wrote: > Thanks Todd! > > > On Dec 4, 2012, at 6:04 PM, Todd Lipcon <t...@cloudera.com> wrote: > >> 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 -- Todd Lipcon Software Engineer, Cloudera