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."
The reason for this proposal is this bugzilla [1] and this blocker ticket [2] 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 [2], 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.
Kamil