hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Hadoop Wiki] Trivial Update of "BristolHadoopWorkshop" by SteveLoughran
Date Tue, 01 Sep 2009 15:38:56 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change notification.

The following page has been changed by SteveLoughran:
http://wiki.apache.org/hadoop/BristolHadoopWorkshop

The comment on the change is:
fix number list formatting

------------------------------------------------------------------------------
  The talk looked at the options for long-haul-ness, of which there are
  two
  
- WS-* : the big, comfortable, safe long-haul option, the Airbus A380.
+  1. WS-* : the big, comfortable, safe long-haul option, the Airbus A380.
  You, the passenger, get looked after by the cabin crew.
  
- The floatplane. Agile, can get around fast, but you read the location of
+  1. The floatplane. Agile, can get around fast, but you read the location of
  the life vest instructions very carefully, make a note of the exit in
  the roof and hope that you aren't the one who has to get on the float to
  dock the plane with the boat. It isn't quite as comfy as the big plane,
@@ -233, +233 @@

  
  Projects
   * Apache Hamburg -proposed by Edward Yoon, of Hamas, is it making progress? We need code.
-   * Thread based [http://throb.googlecode.com/svn/trunk/src/java/org/apache/hadoop/hamburg/
prototype code of Hamburg]
+  * Thread based [http://throb.googlecode.com/svn/trunk/src/java/org/apache/hadoop/hamburg/
prototype code of Hamburg]
   * Apache Common Graph. Dead, pre-MapReduce code.
  
  === Graph Algorithms ===
@@ -271, +271 @@

  * Y! are making Hadoop the core of the company; it is their LOB of datacentre.
  
  What are the risks of the Merger, and warning signs of trouble:
-  # silence: Y! developers do their own fork, it goes closed source. We have seen this happen
in other OSS projects (Axis), where a single company suddenly disappears. There is no defence
from this other than making sure development knowledge is widespread. The JIRA-based discussion/documentation
is good here,
+  1.  silence: Y! developers do their own fork, it goes closed source. We have seen this
happen in other OSS projects (Axis), where a single company suddenly disappears. There is
no defence from this other than making sure development knowledge is widespread. The JIRA-based
discussion/documentation is good here,
   as it preserves all knowledge, and makes decisions in the open.
- 
-  # staff departure. Key staff in the Hadoop team could leave, which would set things back.
Moving into MS could be bad, but moving to Google would set back development the worst.
+  1.  staff departure. Key staff in the Hadoop team could leave, which would set things back.
Moving into MS could be bad, but moving to Google would set back development the worst.
-  # slower development/rate of feature addition
+  1.  slower development/rate of feature addition
-  # reduced release rate. This can compensate for reduced testing resources.
+  1.  reduced release rate. This can compensate for reduced testing resources.
-  # reduced rate of bug fixes. We can assume that Y!s own problems will be addressed, then
everything else is other people's problems.
+  1.  reduced rate of bug fixes. We can assume that Y!s own problems will be addressed, then
everything else is other people's problems.
-  # Less testing, reduced quality
+  1.  Less testing, reduced quality
  Apparently under [http://community.cloudera.com] - number of messages/JIRA and infer activity,
such as [http://community.cloudera.com/reports/47/contributors/ contributors] and [http://community.cloudera.com/reports/47/issues/
popular issues]
  
  With Yahoo! outsourcing searching to MS, it means that MS can take on a big project that
-even if it isn't profitable to MS, can be subsidised by other parts of their business. It
ensures Yahoo! continuing survival as an independent company, which is the best state for
Hadoop development. It also frees up some Yahoo! datacentres for other projects. Those big
datacentres are large, slowly-depreciating assets, and by offloading the indexing to someone
else, there is now spare datacentre capacity for Yahoo! to use for other uses, uses that are
highly likely to use Hadoop at the back end -because what else would they build a datacentre-scale
application on?

Mime
View raw message