Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # dev - Re: Heads up - 2.0.5-beta


Copy link to this message
-
Re: Heads up - 2.0.5-beta
Konstantin Shvachko 2013-05-02, 09:08
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 <[EMAIL PROTECTED]> wrote:

>
> On May 1, 2013, at 4:08 PM, Konstantin Shvachko wrote:
>
> > On Wed, May 1, 2013 at 1:15 PM, Arun C Murthy <[EMAIL PROTECTED]>
> 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
>
>