We need a known-good state for rollbacks in case serious issues surface that we can't immediately trace to a specific later release.
In practice this probably just means not cleaning the previous week's train, which is probably already handled by scap clean not deleting anything newer than a week.
May also be handled by just leaving all versions for the week in place.
After discussion: scap clean is time-based, this should not be an issue - the previous week's train should stick around.
Somewhat related to T298046: Provide a way to run Parsoid against "latest git HEAD of mediawiki-vendor" during round trip testing on parsoidtest1001 -- if we're going to have very-frequent trains, the content transform team may wish to be able to pin a specific train version so we can run regression tests (which take a large fraction of a day). Probably keeping every train around for a week is more than enough for our purposes, but if we were to make daily trains routine we'd certainly require trees to be kept around for longer than a day.
@cscott When you say the trees should be kept around, do you mean the wmf/<whatever> branches needs to persist in Gerrit for a week, or do you mean that a given branch needs to remain deployed and active for a week?