Just to be certain, since the above is a bit dense:

The current state is:
RPMs > Fedora Flatpaks > Full Flathub

and the fix would make it:

Fedora Flatpaks > Full Flathub > RPMs
(Fedora Flatpaks and RPMs have no overlap and Full Flathub is only installed by explicit manual action)

Do I have that correct?

Fedora Flatpaks do overlap Fedora RPMs, but otherwise, yes, you have it correct.

I think I remember that our concensus was pretty much that third-party content from flathub should never take precedence over first-party Fedora content, either RPMs or Flatpaks, when we rejected the "Full Flathub by default" proposal?

Given that, I am not sure whether the "fix" proposed here is acceptable, since it would result in Flathub content being preferred over first-party Fedora content. This only happens if a user has explicitly opted into unfiltered flathub, but it might still be surprising (which is why I'm not "100% against" here, just "this still feels wrong").

I'd rather wait until upstream GNOME Software supports setting arbitrary precedence of software sources instead of only supporting limited "Flatpak > RPM" or "RPM > Flatpak" precedence before making any changes that would result in third-party content being preferred over first-party content.

I checked and prioritization of Flatpak over RPM was added upstream by https://gitlab.gnome.org/GNOME/gnome-software/-/commit/c1fb070ce2f0c55c3fb57c6bf3d783c62340af99 in June 2016 - and presumably then was in Fedora 25. So for 11 releases we had the prioritization that way until a bug broke prioritization for Fedora 36.

That sounds like a policy thing from GNOME that wasn't evaluated by Fedora. And at least for most of those 11 releases, we didn't have any Flathub stuff to speak of. And today, filtered Flathub ensures we're not replacing Fedora content with Flathub stuff, so the risk of it being a problem was pretty low. That's why it wasn't flagged until the unfiltered Flathub proposal came in.

That sounds like a policy thing from GNOME that wasn't evaluated by Fedora.

As with many things in the Workstation, this was done by people who work on both Fedora and GNOME. Flatpak support - and for that matter packagekitd support in GNOME Software - was developed primarily so that it could appear in Fedora. This ordering has been discussed many times in the Working Group - you've definitely been part of those discussions. This is not some sort of Easter Egg that "upstream GNOME" snuck in.

When we brought the unfiltered Flathub proposal to the table, we definitely realized - and pointed out - that the combination of unfiltered Flathub in the third-party repository set and this existing prioritization could have undesired effects. But figuring out a path there should be separate from fixing this bug.

Fedora Workstation WG has repeatedly reaffirmed that we always want Flatpaks to be prioritized over RPMs. We understand, based on the previous FESCo decision, that we are not allowed to enable full Flathub unless we change this. We have not yet decided what to do about that, although Fedora Flatpaks > Fedora RPMs > Flathub is a likely possibility. (I'm advocating for removing RPMs altogether instead.)

That is not what we're trying to sort out today. We do not have full Flathub yet. What we want to do here is just revert back to the longstanding status quo that has existed since Fedora 25. We should not need a FESCo ticket to do this, and Fedora QA should not have requested one. The breakage in Fedora 36 is just a bug, not an intentional design change, so a normal freeze exception should suffice.

Just to be certain, since the above is a bit dense:

The current state is:
RPMs > Fedora Flatpaks > Full Flathub

and the fix would make it:

Fedora Flatpaks > Full Flathub > RPMs
(Fedora Flatpaks and RPMs have no overlap and Full Flathub is only installed by explicit manual action)

Do I have that correct?

Almost. The default behavior is Fedora Flatpaks > Filtered Flathub > RPMs. If you manually choose to enable full Flathub, which is not offered by Fedora, then it will work as you describe.

Almost. The default behavior is Fedora Flatpaks > Filtered Flathub > RPMs. If you manually choose to enable full Flathub, which is not offered by Fedora, then it will work as you describe.

I think this is fine for F37, since it matches the expected F35 behavior. I also agree that we don't need to re-litigate the long-term prioritization in this ticket. Let's solve the immediate bug and look at other improvements for F38.

+1

+1

The ordering makes sense and I like the idea of a filtered flathub in the middle with an option to make it full flathub.

I agree that it looks correct to treat the F36 change in prioritization as a bug and fix it in F37 to match previous releases.

+1

I don't want to create pressure on FESCo members, but QA would need the final FESCo decision soon. F37 Final has slipped a week and we have an option to include the new gnome-software build in a new F37 release candidate (that would be highly desirable because of Silverblue, see the bug report). But we need to know soon whether to include the build or not. I believe we're likely to request the new RC on Monday.

+1

how many votes do we need to call this? at this point this is the last thing I'm waiting for to do RC3. with my QA hat on I have no objections to this, I have verified that the F37 behaviour with the update is the same as F35's behaviour was.

Fine. +1

so there's 9 people on fesco and I count 5 +1s, is that all that's needed?

Since @churchyard requested the fast-track procedure, we need seven positive votes with no negative votes for immediate approval.

Formally, the rule is =E2=80=9Cwait a week, unless it=E2=80=99s proposed as=
a fast track,
which this is. In that case, it can skip the week period for counter
arguments if it receives +7.

So it needs +2 more to trigger fast-track.

On Fri, Oct 21, 2022 at 6:52 PM Adam Williamson pagure@pagure.io wrote:

adamwill added a new comment to an issue you are following:
so there's 9 people on fesco and I count 5 +1s, is that all that's needed= ?

To reply, visit the link below or just reply to this email
https://pagure.io/fesco/issue/2880

sigh. i would like to not have to wait on this to do RC3 :|

I know I initially said I'd file this with fesco, but the discussion on chat actually continued after that, and I was not going to file a fesco ticket once I understood that this was just restoring the status quo. but it seems like that signal got crossed and the issue got filed anyway. Filtered log:

<adamw> but anyway, what i was gonna say is - since it's unclear, if a proposal is made (blocker/fe/whetever) to change the preference order for f37 at this time, i'll file a fesco ticket asking them to clarify that, unless they've already said so somewhere
<otaylor> adamw: certainly Fesco (as a group) did not say "hold on, what? Flatpaks are preferred, you need to go and change that now" during that discussion. (I'm not sure what the Fedora mechanism would be for Fesco to force a change on an Edition like that - we've generally treated it like Fesco only has veto power.)
<adamw> well i'm not gonna white knight that on any side. but i'm also not inclined to push a major change like this through the freeze late when there's clearly controversy
<mcatanzaro> It's just a bug like any other... should reset back to the good state
<mcatanzaro> We know we will have to change this again later in order for FESCo to allow us to enable flathub
<mcatanzaro> But that's not something we need to worry about for F37, only for F38
<adamw> of course, if we are interested in what fesco think and want to know, we can ask any time, just file a ticket. i'm just saying from the perspective of the release process that's where i'm at
<adamw> mcatanzaro: sorry, what's "the good state" there?
<mcatanzaro> The intended behavior: Fedora flatpaks > Filtered flathub > RPMs
<mcatanzaro> Anything else is a bug
<mcatanzaro> We know we have to change it for FESCo to allow unfiltered flathub, but that day is not today
<adamw> okay. if that's how it worked before and nobody was setting things on fire, that's fine i guess
<mcatanzaro> That is how it has worked for years
<adamw> so, uh, is the current proposed update (that we left out of the RCs so far) actually 'wrong'? or does it indeed restore the previous behaviour?
<otaylor> As far as I know, it is correct and restores the previous behavior. @kparal reported one testing result that differed from my expectations, but I tried to reproduce it and did not, so I'm not sure what's going on with that, and whether it's different from what happened in Fedora 35.
<adamw> okay. i'll have a look at it myself if we do another rc, but rc2 is already run so it's too late for that :|

at that point I was just going to re-test it myself and send it back through FE process if it turned out this way, but it seems this ticket got filed anyhow.

meh, +1

+1

APPROVED +7,0,-0

Announced.