diff --git a/README b/README
index 4f4944d74fd..7938bae4768 100644
--- a/README
+++ b/README
@@ -41,10 +41,10 @@ This will create a "perl6" or "perl6.exe" executable in the
 current directory.  Rakudo doesn't currently have a "make install"
 target.
 
-The "--gen-parrot" option tells Configure.pl to automatically 
+The C<--gen-parrot> option tells Configure.pl to automatically 
 download (via 'svn') and build the version of Parrot most 
 appropriate for the copy of Rakudo you currently have.  It's
-okay to use the --gen-parrot option on later invocations of
+okay to use the C<--gen-parrot> option on later invocations of
 Configure.pl; the configure system will re-build Parrot only
 if a newer version is needed for whatever version of Rakudo 
 you're working with.
@@ -67,13 +67,13 @@ are preserved after they are defined, but variables are not).
 
 =head2 Running the test suite
 
-Entering "make test" will run a small test suite that comes 
+Entering C<make test> will run a small test suite that comes 
 bundled with Rakudo.  This is a simple suite of tests, designed
 to make sure that the Rakudo compiler is basically working and that
 it's capable of running a simple test harness.
 
-Running "make spectest" will import relevant portions
-of the official Perl 6 test suite from the Pugs repository
+Running C<make spectest> will import the official Perl 6 test suite
+from the Pugs repository
 L<http://svn.pugscode.org/pugs/t/spec/> and run all of these tests that
 are currently known to pass.
 
diff --git a/build/Makefile.in b/build/Makefile.in
index 006e3e870e5..891978f58f6 100644
--- a/build/Makefile.in
+++ b/build/Makefile.in
@@ -358,7 +358,7 @@ manifest:
 	sort -u -o MANIFEST MANIFEST
 
 release: manifest
-	[ -n "$(VERSION)" ] || ( echo "\nTry 'make release VERSION=yyyymm'\n\n"; exit 1 )
+	[ -n "$(VERSION)" ] || ( echo "\nTry 'make release VERSION=YYYY-MM'\n\n"; exit 1 )
 	[ -d rakudo-$(VERSION) ] || ln -s . rakudo-$(VERSION)
 	$(PERL) -ne 'print "rakudo-$(VERSION)/$$_"' MANIFEST | \
 	    tar -zcv -T - -f rakudo-$(VERSION).tar.gz
diff --git a/docs/release_guide.pod b/docs/release_guide.pod
index aa25c52e22d..9c290bdd920 100644
--- a/docs/release_guide.pod
+++ b/docs/release_guide.pod
@@ -80,10 +80,11 @@ prior to the release, addressing them as needed.
 
 Once Parrot issues its monthly release, edit Rakudo's 
 build/PARROT_REVISION file to contain the subversion revision 
-number corresponding to Parrot's monthly release.  
-As always, test to make sure Rakudo still builds and
-passes its tests.  Once build/PARROT_REVISION has been
-set to the Parrot release, it must not be changed until
+number and release number corresponding to Parrot's monthly 
+release.  For example, for June 2009 PARROT_REVISION file
+contained "39599 1.3.0".  As always, test to make sure Rakudo 
+still builds and passes its tests.  Once build/PARROT_REVISION 
+has been set to the Parrot release, it must not be changed until
 after the Rakudo release.  In other words, we want each
 monthly release of Rakudo to be able to be built using
 the immediately prior release of Parrot.
@@ -100,6 +101,8 @@ As the actual release date nears, review the git log history
 to see if any additional items need to be added to the ChangeLog.
 This can be conveniently done with  "git log --since=yyyy-mm-dd --reverse".
 
+  $ git commit docs/ChangeLog
+
 =item 5.
 
 When it's time to cut the release, create a new release announcement
@@ -110,12 +113,17 @@ some small details about the choice of release name.  (If the
 details are a bit lengthy, this can often best be done as a separate
 section at the bottom of the announcement.)
 
+  $ git add docs/announce/YYYY-MM
+  $ git commit docs
+
 =item 6.
 
 Update the release dates and names at the top of this file
 (docs/release-guide.pod).  Also improve these instructions if
 you find any steps that are missing.
 
+  $ git commit docs/release-guide.pod
+
 =item 7.
 
 Make sure everything compiles and runs from a known clean state:
@@ -127,14 +135,20 @@ Make sure everything compiles and runs from a known clean state:
   $ make spectest
 
 Continue adjusting things until make spectest passes as expected.
+Often this means fixing a bug, fudging a test, or removing a
+test from t/spectest.data .  Use your best judgement or ask others
+if uncertain what to do here.
 
 =item 8.
 
 Make sure any locally modified files have been pushed back to github.
 
+  $ git status
+  $ git push
+
 =item 9.
 
-Create an initial tarball by entering "make release VERSION=YYYY-MM",
+Create an initial tarball by entering C<make release VERSION=YYYY-MM>,
 where YYYY-MM is the month for which the release is being made.
 This will create a candidate tarball file named <rakudo-YYYY-MM.tgz>.
 
diff --git a/src/classes/Array.pir b/src/classes/Array.pir
index 027ab2c1401..abfaf6773d3 100644
--- a/src/classes/Array.pir
+++ b/src/classes/Array.pir
@@ -175,7 +175,7 @@ Add C<args> to the end of the Array.
   it_loop_end:
     $I0 = elements self
     splice self, args, $I0, 0
-    .tailcall self.'elems'()
+    .return (self)
   type_error:
     'die'('Type check failure in push')
 .end
@@ -238,7 +238,7 @@ Adds C<args> to the beginning of the Array.
     goto it_loop
   it_loop_end:
     splice self, args, 0, 0
-    .tailcall self.'elems'()
+    .return (self)
   type_error:
     'die'('Type check failure in push')
 .end