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." https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria#Data_corrupt... (see footnotes for some additional details)
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
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1881495 [2] https://pagure.io/fedora-qa/blocker-review/issue/118
On Thu, Jan 7, 2021 at 5:44 AM Kamil Paral kparal@redhat.com wrote:
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.
My recollection is the older Firefox did ship on beta media. There wasn't a newer successfully built Firefox still.
But yeah, I support moving the criterion to beta. The language says "must be fixed or documented" - who decides which? It reads like there are up to three decisions to make for this criterion: 1) is it a blocker? 2) should it be documented or fixed for beta? 3) should it be documented or fixed for final?
On Fri, Jan 8, 2021 at 5:58 AM Chris Murphy lists@colorremedies.com wrote:
On Thu, Jan 7, 2021 at 5:44 AM Kamil Paral kparal@redhat.com wrote:
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.
My recollection is the older Firefox did ship on beta media. There wasn't a newer successfully built Firefox still.
Perhaps you're right and the older FF was on media, and the newer FF was just in updates. It doesn't really matter much, it's just an example of a potential issue.
But yeah, I support moving the criterion to beta. The language says "must be fixed or documented" - who decides which?
See this footnote under the criterion: "Fixed or documented? If the issue is sufficiently serious, we may consider that documenting it is not sufficient and it must be fixed. This is a subjective determination that will be made at blocker review or Go/No-Go meetings."
It reads like there are up to three decisions to make for this criterion: 1) is it a blocker? 2) should it be documented or fixed for beta? 3) should it be documented or fixed for final?
Yes, that sounds right. We can for example decide that it's sufficient to have it documented for Beta, but it needs to be fixed for Final.
On Fri, Jan 8, 2021 at 3:47 AM Kamil Paral kparal@redhat.com wrote:
Yes, that sounds right. We can for example decide that it's sufficient to have it documented for Beta, but it needs to be fixed for Final.
I like this scenario (at least for some set of data corruption bugs. Each bug is special and unique, of course).
I am in favor of the proposal.
On Thu, Jan 7, 2021 at 1:44 PM Kamil Paral kparal@redhat.com wrote:
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."
https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria#Data_corrupt... (see footnotes for some additional details)
Because there have been only supportive votes and no concerns (nor further comments on the devel list [1]), I implemented the change today: https://fedoraproject.org/w/index.php?title=Fedora_34_Beta_Release_Criteria&... https://fedoraproject.org/w/index.php?title=Fedora_34_Final_Release_Criteria...
Cheers, Kamil
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...