Move status message
diff --git a/tools/finish_release.py b/tools/finish_release.py
index 5113a76b8dd..bc8e832dfb7 100755
--- a/tools/finish_release.py
+++ b/tools/finish_release.py
@@ -166,6 +166,9 @@ def promote_snaps(version):
     assert_logged_into_snapcraft()
     for snap in SNAPS:
         revisions = get_snap_revisions(snap, version)
+        # The loop below is kind of slow, so let's print some output about what
+        # it is doing.
+        print('Releasing', snap, 'snaps to the stable channel')
         for revision in revisions:
             cmd = ['snapcraft', 'release', snap, revision, 'stable']
             try:
@@ -175,9 +178,6 @@ def promote_snaps(version):
                 print("The output printed to stdout was:")
                 print(e.stdout)
                 raise
-        # This loop is kind of slow, so let's print some output about what it
-        # is doing.
-        print('Successfully released', snap, 'to the stable channel.')
 
 
 def main(args):

I just ran this script for the first time through with all of our DNS plugins and I found its output a little misleading. For each snap, I essentially saw it print a message lIke:
```
Getting revision numbers for certbot 1.9.0
```
wait quite a while and then print
```
Successfully released certbot to the stable channel.
```
almost immediately followed by
```
Getting revision numbers for certbot-dns-sakuracloud 1.9.0
```
This timing suggests to me that what is taking so long is getting revision numbers, but the real time is spent calling `snapcraft release` 3 times to publish it for all architectures.

I think adding a status message before calling `snapcraft release` clarifies this and with the "Getting revision numbers message", I think the message after publishing changes isn't needed and is unnecessarily verbose since they are printed one right after the other.

Remember you should feel free to test this out by just running the script and deleting the draft GitHub release as described [here](https://github.com/certbot/certbot/pull/8351#issue-498172023) (or just commenting out the call to `create_github_release` in `main` which is what I have been doing).