I propose we move the existing Data Corruption criterion from Final to
Beta. The criterion sounds like this:
"All known bugs that can cause corruption of user data must be fixed or
documented at Common F34 bugs."
(see footnotes for some additional details)
The reason for this proposal is this bugzilla  and this blocker ticket
 where we discussed whether we should ship an older Firefox on F33 Beta
media, which was known to completely wipe the whole user profile on
upgraded systems. We didn't (and still don't) have any release criterion
which says that this situation should not occur. Fortunately, in the F33
Beta case, we managed to ship a fixed version of Firefox in time, and so we
didn't really need to make a decision back then.
I talked about this problem in general in , and I said:
"I support moving the Data Corruption criterion to Beta, with the rationale
that we also require system upgrades to be fully working at Beta, and that
puts testers into a tough place where they are recommended to upgrade but
might lose personal data. It seems to me that those two things should be
coupled together, for important cases (like this one, IMO). The corruption
criterion allows us to decide when we want to demand the fix and when it's
enough to have it documented. If e.g. all my history+bookmarks+passwords
get purged from Firefox or if e.g. my ~/Documents folder gets removed on
Beta upgrade, I believe we should have an option to block the Beta release.
At the same time, we don't need to apply it if you only lose e.g. your
color profiles in gnome-terminal. Currently your whole home can get purged
and we don't have a way to stop it in Beta, I find that a problem."
The criterion as currently written is flexible enough that it doesn't force
us to fix the issue, if we consider it low-risk or low-impact, but it
*enables us* to have that conversation and accept the high-risk or
high-impact issues as blockers. That's why I believe moving it to Beta
doesn't bring any downsides, just advantages.
Please comment, thank you.