I am not sure what was your point here. You seem to be assuming things I never mentioned.
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. Thanks, --Konstantin On Wed, May 1, 2013 at 6:24 PM, Arun C Murthy <a...@hortonworks.com> wrote: > > On May 1, 2013, at 4:08 PM, Konstantin Shvachko wrote: > > > On Wed, May 1, 2013 at 1:15 PM, Arun C Murthy <a...@hortonworks.com> > wrote: > >> > >> On Apr 30, 2013, at 4:28 PM, Konstantin Shvachko wrote: > >> > >>> If the next release has to be 2.0.5 I would like to make an alternative > >>> proposal, which would include > >>> - stabilization of current 2.0.4 > >>> - making all API changes to allow freezing them post 2.0.5 > >>> And nothing else. > >> > >> I think it's hard to clearly define - 'nothing else'. For e.g. > > YARN-398/YARN-392. It's a 'feature' but worth putting in right-away since > > it so low-risk. MAPREDUCE-5108 is a 'feature' but is critical for > ensuring > > a smooth transition from MR1 to MR2 etc. etc. > >> > > > > Don't see contradictions to the plan here. > > Both YARN-398, YARN-392 are important optimizations. They require API > > changes, so it is better to commit them into 2.0.5. If RM sees a low risk > > in including the implementations, I don't see a problem. > > MAPREDUCE-5108 as a compatibility issue should go in, imho. > > Actually, YARN-398/YARN-392 and other such optimizations can go in in > future too releases in a compatible manner too since we have PB-based > protocols in YARN (as in HDFS). > > However, they serve to illustrate why having a very narrow view of > 'allowed' changes for the next 3-4 weeks will just add needless complexity. > > IAC, like I said it would be better to let individual contributors decide > on risk of individual changes since they are the ones supporting them. > Having a strict policy leads to all sorts of further dialogues and issues > we could do well without. > > thanks, > Arun > >
