Re: [ANNOUNCE] New PMC member Ming Ma
Congratulations Ming. 2016-11-09 10:32 GMT-08:00 Andrew Wang <andrew.w...@cloudera.com>: > Hi everyone, > > I'm very pleased to announce that the Apache Hadoop PMC has voted to add > Ming Ma as a PMC member. This is in recognition of Ming's many > contributions to the Hadoop community. > > Congratulations Ming! Great work! > > Best, > Andrew > -- Have a Nice Day! Lohit
Re: [ANNOUNCE] New Hadoop Committer - Ming Ma
Awesome. Congrats Ming. On Jun 18, 2015 12:57 PM, Arun C Murthy acmur...@apache.org wrote: Congratulations Ming, and thank you! Look forward to your continued involvement and help with the project. Arun On Jun 18, 2015, at 12:55 PM, Chris Nauroth cnaur...@hortonworks.com wrote: On behalf of the Apache Hadoop PMC, I am pleased to announce that Ming Ma has been elected as a committer on the Apache Hadoop project. We appreciate all of Ming's hard work thus far, and we look forward to his continued contributions. Welcome, Ming! --Chris Nauroth
Re: [ANNOUNCE] New Hadoop Committers - Gera Shegalov and Robert Kanter
Congrats Gera and Robert 2014-12-04 13:43 GMT-08:00 Chris Nauroth cnaur...@hortonworks.com: Congratulations! Chris Nauroth Hortonworks http://hortonworks.com/ On Thu, Dec 4, 2014 at 11:56 AM, Sandy Ryza sandy.r...@cloudera.com wrote: On behalf of the Apache Hadoop PMC, I am pleased to announce that Gera Shegalov and Robert Kanter have been elected as committers on the Apache Hadoop project. We appreciate all the work they have put into the project so far, and look forward to their future contributions. Welcome, Gera and Robert! -Sandy -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- Have a Nice Day! Lohit
Re: [VOTE] Release plan for Hadoop 2.0.5
+1 Particularly making 2.0.X stable will help wider adoption sooner. 2013/5/9 J. Rottinghuis jrottingh...@gmail.com +1 (non-binding) to stabilize 2.0, and add new features only after a stable release. I understand that what constitutes as new feature versus stabilizing is subjective. Thanks, Joep On May 1, 2013, at 12:53 PM, Konstantin Shvachko wrote: Please vote on the following plan for Hadoop release 2.0.5 - bug fixes encountered in current release 2.0.4-alpha - make all API changes to allow freezing them post 2.0.5 - no new features As discussed on @dev thread http://s.apache.org/fs this will allow to stabilize 2.0 branch in a short and predictable period of time. This enables a powerful option to have the release tested at Yahoo scale. The plan is to follow up with 2.1.0 - the stable release. New features can and should be added on top of the stable release once it is out. Hadoop by-laws: http://hadoop.apache.org/bylaws.html Release Plan Defines the timetable and actions for a release. The plan also nominates a Release Manager. Lazy majority of active committers assume nomination of a Release Manager with the plan. It would be really good if Arun continues if this plan is adopted. We can return to the RM topic if not. The vote will run for 7 days until next Wed, May 8th. Thanks, --Konstantin -- Have a Nice Day! Lohit
Re: Heads Up - hadoop-2.0.3 release
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
Re: Heads Up - hadoop-2.0.3 release
+1 on having QJM in hadoop-2.0.3. Any rough estimate when this is targeted for? 2012/11/15 Arun C Murthy a...@hortonworks.com On the heels of the planned 0.23.5 release (thanks Bobby Thomas) I want to rollout a hadoop-2.0.3 release to reflect the growing stability of YARN. I'm hoping we can also release the QJM along-with; hence I'd love to know an ETA - Todd? Sanjay? Suresh? One other thing which would be nice henceforth is to better reflect release content for end-users in release-notes etc.; thus, can I ask committers to start paying closer attention to bug classification such as Blocker/Critical/Major/Minor etc.? This way, as we get closer to stable hadoop-2 releases, we can do a better job communicating content and it's criticality. thanks, Arun -- Have a Nice Day! Lohit
Re: [VOTE] Powered by Logo
4,5,6,3,2,1 PS: Powered logo would be advertised by users. Their vote should count :) - Original Message From: Owen O'Malley omal...@apache.org To: general@hadoop.apache.org Sent: Tue, June 14, 2011 8:19:18 PM Subject: [VOTE] Powered by Logo All, We've had a wide range of entries for a powered by logo. I've put them all on a page, here: http://people.apache.org/~omalley/hadoop-powered-by/ Since there are a lot of contenders and we only want a single round of voting, let's use single transferable vote ( STV http://en.wikipedia.org/wiki/Single_transferable_vote). The important thing is to pick the images *IN ORDER* that you would like them. My vote (in order of course): 4, 1, 2, 3, 5, 6. In other words, I want option 4 most and option 6 least. With STV, you don't need to worry about voting for an unpopular choice since your vote will automatically roll over to your next choice. -- Owen
