There is an existing discussion happening inside the bug, because it was created just for that purpose. So it's probably better to keep all discussion there, and then just vote here.

BetaFE +1

This one we can agree on easily, I guess.

BetaBlocker -1
BetaFE +1

BetaBlocker +1
BetaFE +1

Why blocker? There is potential for data loss.

BetaFE +1
BetaBlocker -1

There is data loss, but upgrades (not new installs) are going to be using the repos, and as long as we get the update in repos by release day we should be ok (The sooner the better obviously).

Note that this bug depends on another bug Firefox build failure on aarch64 - missing libmozgtk.so

Workstation aarch64 is release blocking. A working Firefox needs to be on that image. I don't think it's desirable or even possible to have different Firefox versions on x64 vs aarch64.

BetaFE +1
BetaBlocker -1

Why blocker? There is potential for data loss.

That's a final criterion (unless you can find a better one). But I already mentioned in the bug that I'd be in favor of moving it to Beta, because I think it's generally reasonable. And then I'd be BetaBlocker +1 on it, because this is a high-profile app and the loss of data can be huge.

There is data loss, but upgrades (not new installs) are going to be using the repos, and as long as we get the update in repos by release day

But we cannot guarantee that we will make it in time. We can vote for a 0Day blocker, though (but that requires moving the data loss criterion to Beta, and then it's a standard BetaBlocker, so the 0Day doesn't make much sense here). It's still risky because some repos might be outdated even on release day (and people can use them directly). There is also a risk of people installing F33 Beta on a separate partition/subvolume from the install medium and then mounting their home.

AGREED AcceptedBetaFE

The following votes have been closed:

• Accepted BetaFE (+5, 0, -0)
  • +1 by kparal, bcotton, zbyszek, kevin, frantisekz

What are your thoughts on moving https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria#Data_corruption to Beta? I really don't think we should risk user profile data for Firefox users. I'm giving this a provisional

BetaBlocker +1

with the assumption that we will make sure a matching criterion is present.

What are your thoughts on moving https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria#Data_corruption to Beta? I really don't think we should risk user profile data for Firefox users. I'm giving this a provisional

BetaBlocker +1

with the assumption that we will make sure a matching criterion is present.

I don't like changing criterions literally day before go/no-go meeting too much. The idea in general seems fine to me, but this should happen in sort of "standard procedure" of proposing the change on test list and having a discussion there, imho.

What are your thoughts on moving https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria#Data_corruption to Beta?

+1

I don't like changing criterions literally day before go/no-go meeting too much. The idea in general seems fine to me, but this should happen in sort of "standard procedure" of proposing the change on test list and having a discussion there, imho.

Sure, I don't like it either. I'm not saying we'll change it just based on the discussion in this ticket. But during go/no-go, there will be a reasonable attendance from different parties, so this is one of the proposals they can approve (or not). I'm just trying to gather your thoughts. If you think go/no-go discussion is not satisfactory, we can do what we did in the past - agree that we intend do perform this change and accept this as a blocker prematurely, and then send out the proposal to test list and finalize it there. It's likely going to end up as we expected, but if it doesn't - well, we wasted a week, that's all.

I don't like changing criterions literally day before go/no-go meeting too much. The idea in general seems fine to me, but this should happen in sort of "standard procedure" of proposing the change on test list and having a discussion there, imho.

Sure, I don't like it either. I'm not saying we'll change it just based on the discussion in this ticket. But during go/no-go, there will be a reasonable attendance from different parties, so this is one of the proposals they can approve (or not). I'm just trying to gather your thoughts. If you think go/no-go discussion is not satisfactory, we can do what we did in the past - agree that we intend do perform this change and accept this as a blocker prematurely, and then send out the proposal to test list and finalize it there. It's likely going to end up as we expected, but if it doesn't - well, we wasted a week, that's all.

So, no, all I am saying is that we should discuss this at the meeting tomorrow and don't change the criteria and accept this as a blocker before. As I understood your original message that you want to go ahead and accept this as a blocker before go/no-go.

What are your thoughts on moving https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria#Data_corruption to Beta?

I'm firmly a -1 on that. We clearly state on installation of prereleases that there may be serious bugs in the Beta release. I'd be okay with whole filesystem corruption as a Beta blocker, but not individual packages, no matter how important. (FWIW, I wouldn't block on "profiles are reset" at Final either; I'd block on the known CVE issues.)

BetaBlocker -1

BetaBlocker -1

As I understood your original message that you want to go ahead and accept this as a blocker before go/no-go.

Not really, I wanted to get the discussion started and some ideas presented. People seem to have wide-ranging opinions on this, so the go/no-go meeting is probably the best place to decide this. Doesn't really matter now, the go/no-go meeting is happening today :-)

I'll probably not able to attend go/no-go, but 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 all my history+bookmarks+passwords get purged from Firefox or if 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.

I wouldn't block on "profiles are reset" at Final either

If that happened to me and Fedora devs would knowingly ship it, that would be the last Fedora release I'd ever use. I don't see anything more important than personal data.

If all my history+bookmarks+passwords get purged from Firefox

Cannot this be overridden by logging into Firefox and sync with their servers?

or if my ~/Documents folder gets removed on Beta upgrade ... Currently your whole home can get purged and we don't have a way to stop it in Beta, I find that a problem.

But this has not been reported in the bug, has it? I don't understand why downgrading of Firefox would delete your entire home.

I agree that this would be a big problem, but I have not seen someone complaining about that. Where can I learn more about it?

If all my history+bookmarks+passwords get purged from Firefox

Cannot this be overridden by logging into Firefox and sync with their servers?

Sure it can be mitigated. You can also back up your whole home before doing the upgrade, or even back up regularly (what an idea!:-)). The question is not whether you can save your data if you know about it beforehand or if you're diligent about backing up (sure you can), but whether a decent portion of our users might lose their data because they do none of those (yes, likely).

or if my ~/Documents folder gets removed on Beta upgrade ... Currently your whole home can get purged and we don't have a way to stop it in Beta, I find that a problem.

But this has not been reported in the bug, has it? I don't understand why downgrading of Firefox would delete your entire home.

No, that was just an example of why I think the Data Corruption (loss) criterion is a good fit for Beta. Because if the upgrade really purged all your documents or even home, I hope even Stephen wouldn't argue against blocking on it. But we currently don't have a criterion that would apply, and I think this is a good time to make it happen (because we already have a similar, albeit less severe scenario).

I agree that this would be a big problem, but I have not seen someone complaining about that. Where can I learn more about it?

The loss of Firefox profile is mentioned here:
https://bugzilla.redhat.com/show_bug.cgi?id=1881495#c5
https://bugzilla.redhat.com/show_bug.cgi?id=1881495#c7

The loss of anything else was just an additional example, sorry if that wasn't clear.

I wouldn't block on "profiles are reset" at Final either

If that happened to me and Fedora devs would knowingly ship it, that would be the last Fedora release I'd ever use. I don't see anything more important than personal data.

Sorry, I was a bit too brief there. I meant that I wouldn’t call it a blocker for install media; I’d support it being a blocker for 0day though.

I agree with sgallagh. We need to have updated firefox available in the repos so that distro upgrades don't end up downgrading firefox, but it's ok to have an older one on the release media.

Of course, if we end up respinning anyway, let's pull in the new firefox but I don't think it should be a blocker for Beta.

Sorry, I was a bit too brief there. I meant that I wouldn’t call it a blocker for install media; I’d support it being a blocker for 0day though.

OK, but 0day only makes sense for things which are not present on install media. Therefore you can't be burned by using the broken version. And when you try to install it, you get the fixed version immediately (because it's in stable repos on release day). Firefox is not this case.

The whole data loss argument is about upgrades though, not install -- and if it's in the stable repos that's enough for upgrades to pick up the new build. It's especially true after Beta and before the Final freeze because during that time, anything that goes to stable replaces the previous package in the repos, so there's no chance upgrades would pick up the older version once it's out in the repos.

OK, but 0day only makes sense for things which are not present on install media. Therefore you can't be burned by using the broken version. And when you try to install it, you get the fixed version immediately (because it's in stable repos on release day). Firefox is not this case.

Except the version on the disk wouldn't be broken. It's only broken for upgrades from an existing install, which you don't (can't) use install media for.

I'm with @kparal on this one. People may upgrade using install media without pulling updates from the net immediately. In particular, people may use install media when the connection is metered or slow. Thus, it is quite realistic to use the package on the install media even if there's an update available on mirrors.

but whether a decent portion of our users might lose their data because they do none of those (yes, likely).

Exactly. I'd be quite inconvenienced if I lost my firefox profile, backups and sync nonwithstanding. And if I learnt that Fedora knew that this was possible and even had a version ready which fixes the issue, but let me install the bad update because to avoid a respin, I would be very disappointed.

Except the version on the disk wouldn't be broken. It's only broken for upgrades from an existing install, which you don't (can't) use install media for.

You're right, but there are still some edge cases like I mentioned in comment-687845. I admit the number of such cases will probably be low. (Just a reminder, for the 0Day blocker to be accepted we still need some matching criterion).

However, since the update has just been requested to go stable, this discussion gets probably academic :wine_glass: . And if FF is already part of stable repos by tomorrow (way ahead of the release date), I agree that the BetaBlocker might not be necessary. So let me change my vote (you convinced me, but 0 because of the edge cases):

BetaBlocker 0
0Day +1

And the 0Day vote will get meaningless if the firefox update truly hits stable repos today or tomorrow.

PS: Have you noticed that we have no way of distinguishing 0Day between Beta and Final? That's because we never needed it and didn't occur to us to introduce Beta0Day and Final0Day keywords :smile:

zbyszek, how do you upgrade using install media? We haven't supported that for a long-long time.

I don't think upgrades using install media can work in a general case (which is why we only support online upgrades now). Let's consider just what would happen if you tried to upgrade, let's say, F31+updates to to F32 using install media. (This is a very similar case as F32+updates to F33 Beta.) Note that F31+updates is a moving target, which currently has firefox-80.0-1.fc31. Soon it's going to get firefox 81. In the mean time, F32 install media has a fixed firefox version: firefox-75.0-1.fc32. If you now somehow (against all the upgrade advice that Fedora has put out) do an upgrade using install media, you'll go from firefox 80.0 to 75.0. And that results in exactly the same kind of breakage and downgrade that we are discussing here.

With this, I am just trying to show the absurdity of supporting upgrades using install media -- it's unsupportable. So even if we ship firefox 81 on the F33 beta install media now, we are soon again in a situation where F32+updates has firefox 82 and our install media still has 81.

Now, I do think it's super important that we get a new firefox out in the F33 repos: we need that asap to fix the upgrades. But it's not install media where the updated firefox needs to go :)

Hmm, OK.
BetaBlocker 0

BetaBlocker -1

BetaBlocker -1

The data loss argument is the most concerning thing here, but this is just a theoretical problem that might possibly occur if the versions in question are incompatible, not something that has been demonstrated to actually occur on upgrade from F32 to F33. What's important here is to ensure we have shiny new Firefox in the updates repo so that users who install beta can upgrade to the current release in a timely manner.

The data loss argument is the most concerning thing here, but this is just a theoretical problem that might possibly occur if the versions in question are incompatible, not something that has been demonstrated to actually occur on upgrade from F32 to F33.

You are mistaken here, see @kparal`s comment where he links two cases of such data loss.

BetaBlocker -1

No beta criterion for this. So it can't be 0Day either.

Ah, from the bug: "Yup, I lost everything when I upgraded from F32 to F33 on Sunday." That's pretty bad. I see the argument for requiring 0day fix to ensure updated Firefox is always used for system upgrades.

0day +1

No beta criterion for this. So it can't be 0Day either.

I don't think we need to be slaves to the release criteria here. Losing your entire Firefox profile is really bad.

AGREED RejectedBetaBlocker

Discussed during the 2020-09-24 Fedora 33 Go/No-Go meeting: [0]

The decision to classify this bug as a "RejectedBlocker (Beta)" was made as a fixed package has been built and will be available in the stable repo on release day.

[0] https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-09-24/f33-beta-go_no_go-meeting.2020-09-24-17.00.txt

The following votes have been closed:

• Rejected BetaBlocker (+0, 2, -8)
  • 0 by zbyszek, kparal
  • -1 by bcotton, kevin, frantisekz, sgallagh, lruzicka, sumantrom, catanzaro, chrismurphy

Release F33 is no longer tracked by BlockerBugs, closing this ticket.