GitLab

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.

All the commands below should checkout the right branch. Besides,
this sentence was wrong for release candidates: when reading it we haven't
merged devel into testing yet, so "selecting" (whatever that means)
the testing branch won't do anything useful.

One needs to get the right doc from the start.

We haven't had access to the relevant RT queues for years
and so far we've survived it, so let's not pretend the RMs
actually check them.