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
MapReduce >> mail # dev >> Heads up - 2.0.5-beta


+
Arun C Murthy 2013-04-26, 01:34
+
Arun C Murthy 2013-04-29, 04:03
Copy link to this message
-
Re: Heads up - 2.0.5-beta
On Fri, Apr 26, 2013 at 11:15 AM, Arun C Murthy <[EMAIL PROTECTED]> wrote:
>
> On Apr 25, 2013, at 7:31 PM, Roman Shaposhnik wrote:
>
>> On Thu, Apr 25, 2013 at 6:34 PM, Arun C Murthy <[EMAIL PROTECTED]> wrote:
>>
>>> With that in mind, I really want to make a serious push to lock down APIs and wire-protocols for hadoop-2.0.5-beta.
>>> Thus, we can confidently support hadoop-2.x in a compatible manner in the future. So, it's fine to add new features,
>>> but please ensure that all APIs are frozen for hadoop-2.0.5-beta
>>
>> Arun, since it sounds like you have a pretty definite idea
>> in mind for what you want 'beta' label to actually mean,
>> could you, please, share the exact criteria?
>
> Sorry, I'm not sure if this is exactly what you are looking for but, as I mentioned above, the primary aim would be make the final set of required API/write-protocol changes so that we can call it a 'beta' i.e. once 2.0.5-beta ships users & downstream projects can be confident about forward compatibility in hadoop-2.x line. Obviously, we might discover a blocker bug post 2.0.5 which *might* necessitate an unfortunate change - but that should be an outstanding exception.
>
> Hope that helps.

It does make things a bit easier, but here's what I'd like to find
out what *level* of feedback from downstream components
and DevOps community would be considered adequate for a
release to be called beta.

IOW, would it make sense for us as a community, to make
the following things as part of the release criteria as far
as downstream components are concerned:
   * producing Maven artifacts of downstream components
     against branch-2 artifacts.
   * having unit test jobs for all the downstream components
     against branch-2 artifacts
   * having all the failures in those unit tests triaged and filed
     either against a component itself or hadoop
   * running Bigtop integration tests on branch-2 nightly
   * having all the failures of unit tests triaged and filed
     either against components or hadoop

Obviously, quantifying DevOps feedback and involvement
is more difficult, but would it be completely out of the question
to, essentially, predicate beta on some level of feedback
coming from Yahoo!/LI/FB/etc?

Thanks,
Roman.

P.S. Note that most of those things Bigtop can help with -- so lets
not get hung up on resources too much for now -- but rather on
whether we'd want those to be part of the release criteria
IF we had all the resources.
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