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 Plain View
Hadoop >> mail # dev >> Re: Heads up - 2.0.5-beta


+
Suresh Srinivas 2013-04-26, 01:36
+
Arun C Murthy 2013-04-26, 18:02
+
Konstantin Shvachko 2013-04-26, 23:34
+
Arun C Murthy 2013-04-27, 01:06
+
Konstantin Shvachko 2013-04-30, 23:28
+
Arun C Murthy 2013-05-01, 20:15
+
Konstantin Shvachko 2013-05-01, 23:08
Copy link to this message
-
Re: Heads up - 2.0.5-beta

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
+
Chris Douglas 2013-05-02, 07:07
+
Konstantin Shvachko 2013-05-02, 09:11
+
Chris Douglas 2013-05-03, 00:53
+
Konstantin Shvachko 2013-05-02, 09:08
+
Arun C Murthy 2013-05-02, 22:05
+
Konstantin Shvachko 2013-05-03, 08:06
+
Robert Evans 2013-05-03, 15:23
+
Konstantin Shvachko 2013-05-01, 19:13
+
Arpit Agarwal 2013-04-26, 23:52
+
Amir Sanjar 2013-04-26, 02:23
+
Steve Loughran 2013-04-29, 22:37
+
Amir Sanjar 2013-04-30, 02:05
+
Steve Loughran 2013-04-30, 16:48
+
Amir Sanjar 2013-04-30, 17:09
+
Roman Shaposhnik 2013-04-26, 02:31
+
Arun C Murthy 2013-04-26, 18:15
+
Eli Collins 2013-04-26, 19:07
+
Suresh Srinivas 2013-04-26, 21:42
+
Eli Collins 2013-04-26, 22:09
+
Luke Lu 2013-04-26, 20:37
+
Arun C Murthy 2013-04-27, 01:27
+
Konstantin Shvachko 2013-04-26, 23:00
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