Updated the README to reflect recent changes. (#2)

Updated sample code to reflect current object names.
Also added a link to the opensfs fork of the buildbot
project.

Signed-off-by: Giuseppe Di Natale <[email protected]>

Author: dinatale2

README.md

@@ -15,8 +15,6 @@ The Lustre project relies on Gerrit to track proposed changes.  Changes
 submitted to Gerrit are called patch sets. Each patch set submitted will 
 be automatically tested by the buildbot.  As you fix the code and push
 new changes to Gerrit, each patch set is queued to be tested.
-Currently, all patch sets submitted are built using SPL and ZFS version
-0.6.5.4.
 
 ### Builder Types
 
@@ -63,7 +61,7 @@ This means the logic for a particular build step can be separated from the
   * `/etc/buildslave` - This file is dynamically generated by the
     `bb-bootstrap.sh` script and is run at boot time by the ec2 user data
     facility.  It includes all the information required to configure and
-    start a latent buildslave.  Most importabtly for scripts this includes
+    start a latent buildslave.  Most importantly for scripts this includes
     the `BB_NAME` variable which is set to the build slave name.
 
 * Provides a consistent way to trap and handle signals from the buildbot
@@ -107,7 +105,7 @@ process begins by adding the new builder and slave to the `master.cfg` file.
 One important thing to be aware of is that each builder can potentially have
 multiple build slaves.
 
-The first step is to determine what kind of slave your setting up.  Both
+The first step is to determine what kind of slave you're setting up.  Both
 standard and latent build slaves are supported.
 
 Once you've added your slaves, be sure to add them to the `all_slaves` list 
@@ -118,10 +116,8 @@ how to add various types of slaves.
 * Linux based m3.large EC2 slave
 ```
 newslaves = [                                                                                     
-     M3LargeEC2SpotSlave(
+     LustreEC2Slave(
          name="slavename",
-         master=bb_master, 
-         url=bb_url,
          ami="ami-xxxxxxxx"
      ),
      ....
@@ -131,31 +127,14 @@ newslaves = [
 * Suse based m3.large EC2 slave
 ```
 newslaves = [                                                                                     
-     M3LargeEC2SuseSpotSlave(
+     LustreEC2SuseSlave(
          name="slavename",
-         master=bb_master, 
-         url=bb_url,
          ami="ami-xxxxxxxx"
      ),
      ....
 ]
 ```
 
-* Persistent build slave
-```
-newslaves = [                                                                                     
-     BuildSlave(
-         name="slavename",
-         password="password"
-     ),
-     ....
-]
-```
-
-EC2 backed slaves do not require `master` or `url` to be provided. 
-`master` and/or `url` are only necessary if you are standing up your own Lustre
-Buildbot instance.
-
 Now that your build slaves have been added, a builder needs to be created which
 owns them.  Jump down to the the BUILDERS section and add a
 `LustreBuilderConfig` entry to the appropriate list.  Each builder must
@@ -182,13 +161,11 @@ http://build.lustre.org/ and it leverages Gerrit's stream-events functionality
 to queue changes to test. Developers are encouraged to use this infrastructure
 when working on a change. However, this code can be used as a basis for
 building a private build and test environment.  This may be useful when working
-on extending the testing infrastructure itself.
+on extending the testing infrastructure itself. We also maintain our own fork of
+the open source Buildbot project which can be found at
+https://github.com/opensfs/buildbot.
 
 Generally speaking to do this you will need to create a `password.py` file
 with your credentials, then list your builders in the `master.cfg` file, and
 finally start the builder master.  It's assumed you're already familiar with
 Amazon ec2 instances and their terminology.
-
-## Licensing
-
-See the [LICENSE](LICENSE) file for license rights and limitations.