Thanks Todd!
On Dec 4, 2012, at 6:04 PM, Todd Lipcon <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> >>>> On Mon, Nov 19, 2012 at 6:09 PM, Siddharth Seth >>>> <[email protected]> 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 <[email protected]> >>>> 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" <[email protected]> wrote: >>>>>> >>>>>>> On Fri, Nov 16, 2012 at 3:38 PM, Aaron T. Myers <[email protected]> >>>> 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
