Update to refer to section 1 of README.developer and other changes to try

and clarify some sections.



git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@2805 7ae35d74-ebe9-4afe-98af-79ac388436b8

README.betatester

@@ -1,11 +1,11 @@
 Hamlib - (C) Frank Singleton 2000 (vk3fcs@ix.netcom.com)
          (C) Stephane Fillod 2000-2007
-         (C) The Hamlib Group 2000-2009
+         (C) The Hamlib Group 2000-2010
 
 * Why does Hamlib need beta-testers?
 
-Hamlib is developed by a team of enthusiasts around the world, for fun,
+Hamlib is developed by a team of radio enthusiasts around the world, for fun,
-much in the spirit of hamradio. (Note that it is not restricted for ham
+much in the spirit of ham radio. (Note that it is not restricted for ham
 usage only). There are a great deal of protocols and rigs around the world
 developers may not own. However, protocols may be available, so backends
 can be implemented, but cannot always be tested by developers. That's where 
@@ -18,19 +18,19 @@ Feedback and improvement requests are also valuable.
 * Okay, you volunteer as beta-tester, how to proceed?
 
 First of all, you can start testing official releases. They are easier to
-test because they come in precompiled and packaged (.rpm, .deb) but they
+test because they come in precompiled and packaged (.rpm, .deb, etc.) but they
 have the drawback of being older than the SVN repository. Reports from these
-versions are still very appreciated, on hamlib-developer@lists.sourceforge.net
+versions are still very appreciated.  Please send them to the 
-mailing list.
+hamlib-developer@lists.sourceforge.net mailing list.
 
 However, the development of Hamlib is still very active, so it's better to
 test from the latest SVN version of the code.  And, depending on feedback you
 make, developers can commit a fix, so you can try out the change soon after,
 without waiting for the next official version.
 
-So to proceed, you will have first to obtain either a snapshot or a check out
+To proceed, you will have first to obtain either a daily snapshot or a check out
-of the latest sources from SVN, then rebuild the Hamlib package and finally
+of the latest sources from the SVN repository, then rebuild the Hamlib package 
-test it with your rig. Don't worry, it's much simpler than how it looks,
+and finally test it with your rig. Don't worry, it's much simpler than it looks,
 despite the size of the package.
 
 Pre-requisite:
@@ -44,7 +44,7 @@ So here we go:
 * Daily SVN trunk snapshots:
 
 Download the latest SVN trunk snapshot from http://n0nb.users.sourceforge.net
-You'll find a tar ball with a name like hamlib-1.2.10svn-20090306.tar.gz,
+You'll find a tarball with a name like hamlib-1.2.10svn-20090306.tar.gz,
 i.e. a check out made 06 Mar 2009, ready for building using the familiar
 "three step" (see below).  Each morning by about 1130z a new snapshot is
 generated and uploaded and the prior day's version is removed.
@@ -59,12 +59,12 @@ See `configure --help' for more information.
 
 * SVN checkout:
 
-Please read the beginning of README.developer file, especially about how to
+Please read the beginning of README.developer file, especially Section 1 which
-obtain a SVN checkout, what are the required tools and versions (very 
+details the SVN checkout, the required tools and versions (very important or
-important or make won't even work!), and how to use autogen.sh.
+make won't even work!), and how to use the autofixer.sh or autogen.sh scripts.
 
 
-* Build:
+* SVN Daily Snapshot Build:
 
 Reading the INSTALL file in top directory will explain in more detail how
 to do the following commands. 
@@ -76,7 +76,9 @@ to do the following commands.
 The prefix argument is optional.  Convention is that local packages be placed
 in /usr/local away from distribution installed packages and this is the default
 location for the snapshots.  The --disable-static option speeds up compilation
-if you don't plan to use static libraries.
+if you don't plan to use static libraries.  Other useful options are
+--without-perl-binding and --without-python-binding if scripting language
+support is not needed (has no effect on rigctld or rotctld).
 
 If you don't want the build files cluttering the source directories, do the 
 following in the same parent directory of hamlib:
@@ -92,7 +94,8 @@ This will keep the binary output files seperate from the source tree.
 * Structure:
 
 For the brave who want to peruse the contents, here are what all the
-subdirectories are for (these are just a sample as more are added):
+subdirectories are for (these are just a sample as more are added from time to
+time):
 
 alinco,aor,icom,
 jrc,kachina,kenwood,
@@ -115,23 +118,25 @@ tests:			rigctl/rotctl and various C programs for testing
 
 * testing Hamlib:
 
-Don't attempt to test Hamlib from source directory unless you're a developer
+Don't attempt to test Hamlib from the source directory unless you're a developer
-and you understand what are the side effects of *not* installing freshly
+and you understand the side effects of *not* installing freshly generated 
-generated objects (basically having to mess with LD_LIBRARY_PATH and .libs).
+objects (basically having to mess with LD_LIBRARY_PATH and .libs).
 
 So here we go. First of all, identify your rig model id.  Make sure 
-/some/where/bin is in your $PATH, as rigctl has to be reachable. Run 
+/usr/local/bin (or the path you set --prefix to above) is in your $PATH, as
-`rigctl -l' to get a list of rigs supported by Hamlib.
+rigctl has to be reachable by your shell. 
 
-If you cannot find yours in the list, please report to the hamlib-developer
+Run `rigctl -l' to get a list of rigs supported by Hamlib.
-mailing list. The protocol manual and rig specifications will help a lot.
+
+If you cannot find your radio in the list, please report to the hamlib-developer
+mailing list. The protocol manual and rig specifications will help us a lot.
 
 You found your rig's ID?  Good!  You're almost ready to use rigctl.
 Have a quick look at its manual page:
 
     man rigctl
 or:
-    man -M /some/where/man rigctl
+    man -M /usr/local/man rigctl
 or simply:
     rigctl --help
 
@@ -166,12 +171,15 @@ _       get_info                should give remote Id and firmware vers
 NB: some functions may not be implemented in the backend or simply not
 available on this rig.
 
-When reporting to hamlib-developer mailing list, please include traces and
+When reporting to the hamlib-developer mailing list, please include traces and
 also comments to tell developers if the action performed correctly on the rig.
 
 Tip: traces can be hard to cut and paste sometimes. In that case,
-    there's a handy tool for you:  script(1). It will make
+    there's a handy tool for you:  script(1) (the (1) is not a part of the 
-    a typescript of everything printed on your terminal.
+    command, rather it is a Unix convention telling which section of the manual
+    it is found, in this case section 1, user commands.  e.g. `man 1 script'). 
+    It will make a typescript of everything printed on your terminal and save it
+    to the file you give it.
 
     $ script my_rig_traces.txt
     Script started, file is my_rig_traces.txt
@@ -195,7 +203,7 @@ Tip: traces can be hard to cut and paste sometimes. In that case,
 And then send my_rig_traces.txt to the hamlib-developer mailing list.
 
 
-Some models needs S-meter calibration, because the rig only returns raw
+Some models need S-meter calibration, because the rig only returns raw
 measurement.  It's easy, it takes only 10mn. Here's how to proceed:
 
  1. Fire up the rigctl program released with the Hamlib package,
@@ -209,11 +217,12 @@ measurement.  It's easy, it takes only 10mn. Here's how to proceed:
  6. Send the table to the hamlib-developer mailing list and it will be added
     in the next release of Hamlib. 
 
-NB: you have to know the S-Meter of radio's is far from being accurate.
+NB: It is well known the S-Meter of any given radio is far from being accurate.
-For owners with a fully equipped lab, you may want to make the up-mentioned
+For owners with a fully equipped lab, you may want to make the above-mentioned
-measurements with a good Signal Generator and a set of calibrated attenuators.
+measurements with a good signal generator and a set of calibrated attenuators.
-Greg W8WWV has an insightful page about S-Meter:
+Greg W8WWV has an insightful page about S-Meter calibration:
-    http://www.seed-solutions.com/gregordy/Amateur%20Radio/Experimentation/SMeterBlues.htm
+    
+http://www.seed-solutions.com/gregordy/Amateur%20Radio/Experimentation/SMeterBlues.htm
 
 
 Okay folks, test as much as you can, in the weirdest situations if