explain that the ./publish should happen soon after the scp

otherwise you scp a tarball up but only one version of the website has it.

doc/HACKING

@@ -456,7 +456,6 @@ interesting and understandable.
 
    2.7) Run it through fmt to make it pretty.
 
-
 3) Compose a short release blurb to highlight the user-facing
 changes. Insert said release blurb into the ChangeLog stanza. If it's
 a stable release, add it to the ReleaseNotes file too. If we're adding
@@ -472,15 +471,19 @@ or somebody to try building it on Windows.
 6) Get at least two of weasel/arma/karsten to put the new version number
 in their approved versions list.
 
-7) Sign and push the tarball to the website in the dist/ directory. Sign
-and push the git tag.
-   (That's either "git tag -u <keyid> tor-0.2.x.y-status", then
-    "git push origin tag tor-0.2.x.y-status".  To sign the
-    tarball, "gpg -ba <the_tarball>".  Put the files in
-    /srv/www-master.torproject.org/htdocs/dist/ on vescum.)
+7) Sign the tarball, then sign and push the git tag:
+  gpg -ba <the_tarball>
+  git tag -u <keyid> tor-0.2.x.y-status
+  git push origin tag tor-0.2.x.y-status
+
+8) scp the tarball and its sig to the website in the dist/ directory
+(i.e. /srv/www-master.torproject.org/htdocs/dist/ on vescum). Edit
+include/versions.wmi to note the new version. From your website checkout,
+run ./publish to build and publish the website.
 
-8) Edit include/versions.wmi to note the new version. From your website
-checkout, run ./publish to build and publish the website.
+Try not to delay too much between scp'ing the tarball and running
+./publish -- the website has multiple A records and your scp only sent
+it to one of them.
 
 9) Email Erinn and weasel (cc'ing tor-assistants) that a new tarball
 is up. This step should probably change to mailing more packagers.
@@ -498,3 +501,4 @@ changelog to tor-talk or tor-announce.
 
   (We might be moving to faster announcements, but don't announce until
   the website is at least updated.)
+