Konstantin, On May 2, 2013, at 2:08 AM, Konstantin Shvachko wrote:
> I am arguing against invasive and destructive features proposed for the > release. > Just to remind here they are again, since the history has been wiped out. > > # Snapshots > # NFS gateway for HDFS > # HDFS-347 unix domain socket based short circuits > # Windows support > > Do I understand correctly that you as a Release Manager will allow any > changes in your release? > In the next 3-4 weeks. It is not appropriate for me, or anyone for that matter, to behave like a gatekeeper for a branch or a release. We have established this many times over as being counter-productive (for e.g. see Roy's responses to role of RM on in archives). This is particularly because Hadoop is such a complex system, exacerbated by the fact that this really is an umbrella project which needs to be broken up (HDFS, YARN, MapReduce); hence, no one person can sufficiently police all changes or try to enforce 'thou shalt do this, and this alone' edicts. There are too many shades of gray. IAC, the only role of RM is to gently prod people into working together so that we can get releases out of the door for our users. It shouldn't shock anyone when I confess that I do not have sufficient expertise to argue with you about the list of HDFS features you are calling 'destructive' - I'll warn you that people working on those features might not share your opinion of their work as such, either. *smile* Given this, I urge you, again, to talk to people working on those features, feature-by-feature. Provide your feedback, review their code and please come to a consensus about what release they should be part of. If possible, help them test it; if not, ask them for what testing they have done or plan to do and see if that seems reasonable to you, help them if you can; end of the day, please come to a consensus with them. It's not my place to express opinions about others' work on HDFS; however, under extreme duress, I may confess that my understanding is that HDFS-347 is reasonably well-tested, the only changes needed to support NFS are changes to some apis/protocols (FileID) while the actual feature might come in later and that Snapshots have been worked on collaboratively for a long while. Even then we seem to agree that all necessary protocol changes will go into 2.0.5-beta; so I'm not sure whether we are disagreeing on much at all! If anyone has concerns about YARN/MapReduce I'm willing to participate in a constructive dialogue. So for e.g., the only opinion I can offer for the list here is that it is my understanding that the proposed changes to support Windows in YARN/MR are very contained and hence non-risky. Lots of people have spent more time on adding that feature than I have; hence I'll assign more weight to their opinion of it's stability than my own. None of this means that I'll withhold the release for any of the features - but if someone steps up and says they want to pull it into branch-2 I will not block them. I hope this is reasonable, and that we can all get back to finishing up the release. Clearly, one thing we all need to agree on (quickly) are the rules for compatibility for major/minor/patch releases. I plan to spend more time on it this week and the next. FTR, my opinion is that within a major release we need to be compatible (both APIs and protocols, both user-facing and internal i..e for rolling upgrades etc.), minor releases can add compatible features and patch releases are meant for bug-fixes. thanks, Arun
