I.e. prepare everything that shall be merged into master (when publishing the
release) in a dedicated branch. The only difference is that for RCs,
that branch is forked off master, while for final releases, it's forked from the
release tag.

The platform part is not spoofed anymore:
https://trac.torproject.org/projects/tor/ticket/26146

Now we'll publish all upgrades on the test channel and will use this
for our QA. Only once our QA has passed, $WEBSITE_RELEASE_BRANCH
will be merged, which will advertise the upgrades on the stable channel (for
actual releases) and alpha releases (for anything else) as usual.

Works for me.

It's a little bit mean to give instructions along the lines of "oh, if you had
thought of doing X 3 minutes ago, your life would be easier now".

I prefer the RM to leave it alone than mess it up, so let's give them the option
to decide it's too complicated :)

With the previous order, feature/buster would end up with frozen APT
repositories, which was not intended.

We don't particularly care *here* what's the value of SOURCE_DATE_EPOCH
as long as we set it.

It makes little sense to "correct any displayed error" so don't expect the RM to
do it. Also, commit only once the PO files have been checked + automate
this step.

It would really be sad to ignore the translation work done between the RC and
the final release, after we've specifically asked translators to do it
at RC time.