Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
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
>
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB