I see no reason not to. The package doesn't enable any repos by default, and it makes it easier for Software to handle third-party repo enablement.

Having the repos installed doesn't seem very controversial if they are disabled.

Are there any practical consequences of this? If gnome-software installs the repos on-demand, it's not really needed, is it? Or would this cause gnome-software to display proprietary software in search results without needing to select the opt-in first?

Yes, this change would make the 3rd party repos searchable on a clean install, without having to go through the extra step to install fedora-workstation-repositories first (yes, gnome-software makes it easy, but it's still an extra step, which would be nice to avoid). Note that even if we pre-install the .repo files, there's still a confirmation step in gnome-software that asks the user if they want to enable the disabled repository when they try to install anything from it.

Also, this change would make it possible to bring back the gnome-initial-setup 3rd party repo page where we can explain the 3rd party repo situation a bit and give the user a choice if they want to enable the repos or not.

Hello. I have two considerations.

1. As you know better than me, there was a very long conversation here: https://pagure.io/Fedora-Council/tickets/issue/121, and in some cases it was a little bit heated.
   The conclusion was what we have right now. I think that you shouldn't include the .repo files without discussing it again with the council.

2. In addition we should be very cautious.
   Even now there are a lot of users that consider ANY third party repository (also the ones they have installed manually) as Fedora official repositories. So, if Google Chrome doesn't play Flash stuff, they blame Fedora. They are not interested: enable all, also closed source stuff, they probably are willing to tolerate advertisements (Amazon's results in the search bar?). And OK, everyone is free. We are a little bit accustomed to the modern web sites: accept the cookies, click here to accept the policy, watch that video to continue, close the pop up... :-) all without reading what that stuff really says.

What I would like to say is that many unaware users, rookies, inexperienced users at their first steps, people that don't mind if a software is FLOSS or proprietary, will continue to be lazy: the important thing is that stuff works and it is easy to install. And OK, I'm not the one that uses textual web browsers or that compile all the software from source :-) I'm OK with simplifying things. Facilitate the life to people in their first steps is a great goal: indeed Fedora is not a difficult distribution.
But I fear that including content of third party repositories in the search results, could hurt a great part of loyal Fedora users, and people very keen about philosophy and ethics of Free Software, they could get upset.

Thank you for your attention. And thanks for your amazing work.

@alciregi
The working group must be deliberate and of course defer to the Fedora Council. I definitely want Fedora to be successful and not a PITA for users, but not at the expense of Fedora's mission. I can recall my own frustration with things not working out of the box, and really would have appreciated a more up front, concise, explanation of this philosophy, why things are the way they are, and what's involved in changing that out of the box behavior. I think that part may have gone from messy, fragmented bits of how to's, to just click a button to enable 3rd party repos.

Does there need to be some middle ground where the user should read a blurb about the Fedora philosophy and about the community before they get to enable 3rd party repos? shrug I'm willing to read compelling arguments in favor of that.

Does there need to be some middle ground where the user should read a blurb about the Fedora philosophy and about the community before they get to enable 3rd party repos? shrug I'm willing to read compelling arguments in favor of that.

Sorry. My English is bad, so I fear that I didn't understand.
I perfectly agree that people is free to install any kind of software: as users we are free to do what we want with our system (between the limits of terms and conditions), and Fedora doesn't not impede this.
Indeed one thing that a user usually does after installing Fedora is to install rpmfusion (me too :smile:).
And I perfectly agree that facilitating some tasks could attract more users.

But as far as I can understand "this change would make the 3rd party repos searchable on a clean install" even if the repositories are disabled? And the user will be asked to enable them only when he choose to install the software in question?
IMHO This limits the freedom of such people that are perfectly aware of all these out of the box behaviours. And it could lead to some controversy (among userbase).

No, no, there is no middle ground. The repository is disabled or it is enabled. And users should be aware of what is shipped with Fedora and what is in a third party repository.
Yes, I think that people "should read a blurb about the Fedora philosophy and about the community" before enabling third party repositories. And IMHO right now such blurb is not enough highlighted ;-)

Discussed at today's meeting. I think we seemed to have a rough consensus that the current proposal is unlikely to be permitted by Fedora Council, and there's no point in advancing a proposal that's likely to be rejected. If we install fedora-workstation-repositories by default, then design changes will surely be needed in gnome-software to add more prominent warning messages (e.g. interstitials) when installing proprietary software. Even then, it's not certain Council would approve the change, but I think that would make it possible to present a good-faith proposal with a reasonable chance of acceptance.

We didn't have a lot of time to discuss though, and I'm sure other WG members were still beginning to understand the issue and would appreciate further discussion.

Another possible gotcha upon making it super easy to install 3rd party software (free or non-free) is gnome-software properly handling missing dependencies during major version upgrades, e.g. F30 to F31.

dnf example in a test@ thread on-going now
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/5WVDDQX7NWZROS2EVQZU3C3UMFZM4DGG/

Doesn't gnome-software functionally always use the dnf equivalent of --allow-erasing?

Doesn't gnome-software functionally always use the dnf equivalent of --allow-erasing?

Yes, gnome-software uses --allow-erasing for distro upgrades. Why is that a problem?

I think it avoids the problem people are experiencing with dnf and 3rd party stuff.

What appears to be the case there, is the user uses --allow-erasing for the download, but somehow that flag isn't saved state anywhere, even when also passed along with reboot, into the rebooted offline/upgrade environment and now the upgrade fails.

This blocks other work https://gitlab.gnome.org/GNOME/gnome-initial-setup/issues/59

At the next meeting I will try to help the group determine whether a majority can approve this, or if it needs to be kicked to the Council. i.e. even if we have a majority who approve it, is that adequate?

Proposal for in-ticket voting: Punt this issue to Council. Upon 6 votes, this will be removed from the meeting agenda, and submitted to Council for consideration.

I'd say as currently-proposed, this would be a waste of Council's time. They've previously required that we not display search results for proprietary software by default, and that's exactly what this change would accomplish. So -1 from me.

I would be +1 if we were to change the repos to use enabled_metadata=0. In that case, GNOME Software or gnome-initial-setup could change them to use enabled_metadata=1 after the user enables third-party repos. In that case, the user-facing behavior in GNOME Software would be effectively identical to what we have now, we'd be able to add the third-party repo page to gnome-initial-setup like Allan wants, and we would have a relatively modest change to present to Council.

I feel like this issue requires a bit more discussion and information before we take it forward. For example:

cschalle suggested that the reasons for that may not hold any longer

Do we know what those specific reasons where, and what has changed?

this change would make the 3rd party repos searchable on a clean install

Would it be hard to prevent that?

I'd personally prefer not to presuppose the Council's view and, If we can, I'd prefer to have an open discussion with them, rather than presenting a hard-baked plan for approval/dismissal. If we can get a better idea of what the UX options are, than that would be good preparation.

Would it be hard to prevent that?

Probably not. It would require some changes in GNOME Software.

This is on the agenda for 11 Feb. But I still want to better understand: "Fedora Council asked us to make sure that fedora-workstation-repositories is installed on-demand and not preinstalled. cschalle suggested that the reasons for that may not hold any longer".

@uraeus Can you clarify this? If not, I think it's both a reasonable and simple question to put directly to the Council what their current position is, before going to the effort of UX discussion or mockups in Software.

At today's meeting we agreed that @kalev and I would draft a council ticket, with a proposal to ship the repos but have the metadata disabled.

Draft issue for the Council:

Improving the 3rd party repo experience

This ticket is being posted on behalf of the Fedora Workstation Working Group.

Two years ago, the Council approved the 3rd party software policy. This policy is being used by Fedora Workstation, but we have been unable to build a successful UI around it, largely due to the nature of the policy.

We would like to explore modifying the policy so that we can reliably integrate the 3rd party repos into the workstation experience.

How 3rd party repos work today

The 3rd party repos are a collection of repositories which can be enabled on Fedora Workstation. Each one:

• Contains a single package
• Is hosted externally
• Is approved by the Workstation Working Group as well as Red Hat legal
• Is not built or signed by Fedora
• Can include proprietary software
• Is disabled by default, but has metadata enabled

Today there are four 3rd party repositories, containing the following software: Google Chrome, Steam, the proprietary NVIDIA driver, and PyCharm.

The repos are shipped in a package called fedora-workstation-repos, which must be installed by the user. Theoretically this is supposed to be done as part of a step in initial setup (or through GNOME Software, as a backup).

Once installed, the content of each repo can be searched for and installed (though users must explicitly enable each repo as part of the install process).

Problems with the 3rd party repos

The main problem with the 3rd party repo policy is that it requires the 3rd party repos to be installed from a package. This makes it difficult (and in some cases impossible) to add a straightforward UI for enabling the 3rd party repos. This can be seen in specific issues like:

• gnome-initial-setup has never had a functioning UI for installing the 3rd party repos, and we don't think that it's practical to add one. This is the main place that we want to expose the 3rd party opt-in to users.
• Enabling the 3rd party repos can be slow due to having to refresh package metadata and so on.
• The process of installing from one of the 3rd party repos isn't great for users, since they have to click through confirmation dialogs to enable each one. From a user perspective, the purpose of these dialogs isn't clear.
• GNOME Software has to carry additional complexity to handle the 3rd party repositories, including special UI in the repository settings and the dialogs for enabling each repository.

Installing the 3rd party repos through a package is also a critical issue for Silverblue, since it requires package layering, which requires a restart to even start using the repositories.

A possible solution

The Workstation WG would love to discuss solutions to these practical problems, while continuing to retain the principles behind the original 3rd party repo policy. One potential solution that we have come up with would be to:

1. Include fedora-workstation-repos in the workstation install media, with all its repos disabled and with metadata turned off.
2. Add UI to initial setup, to allow users to opt into the 3rd party repos. This would enable both the repositories and their metadata, and would be explicit about the proprietary nature of their content.

This arrangement would prevent users from being exposed to any sight of the 3rd party repo content until they have explicitly enabled them. It would also enable us to build a functional and reliable UI on top of the 3rd party repos.

We look forward to your feedback and discussing this further!

Draft looks good to me.

I've filed the ticket with the council: https://pagure.io/Fedora-Council/tickets/issue/289

I've filed the ticket with the council: https://pagure.io/Fedora-Council/tickets/issue/289

This has been approved. Next steps:

• update any documentation that needs updating
• design the new 3rd party repos UX (get feedback on this from the council)
• implement all the things

Initial mockup for a refreshed initial setup page:

Looks nice! A few random comments:

• "This software is proprietary" -- this is actually not true. PyCharm is open source, it's just that it's maintained in a copr and not in Fedora proper.

• "from the Software Sources settings in Software" -- it's called "Software Repositories"

• If we don't want to put the hardcoded list of what's in the third party repos into gnome-initial-setup, we could possibly get the list (or the whole first paragraph of the text) from "fedora-workstation-repositories" package description. This would sadly make it non-translatable though, hm.

Nit: does GNOME have a style rule regarding Oxford comma? I think we normally use it, but it's conspicuously missing here.

Regarding package names, it'd be better to avoid hardcoding anything that we don't want to become outdated. ;) I think it's safe to say Google Chrome, NVIDIA, and Steam are here to stay. For PyCharm, my first question as a non-Python developer is "what's PyCharm?" and my second question is "is it important enough to mention in gnome-initial-setup?"

Updated wording:

Nit: does GNOME have a style rule regarding Oxford comma? I think we normally use it, but it's conspicuously missing here.

Checking with fesco to see what we should do with the policy docs: https://pagure.io/fesco/issue/2355

PR to update fesco-docs: https://pagure.io/fesco/fesco-docs/pull-request/27

Well, this has been approved. We never actually implemented it, though.

Well, this has been approved. We never actually implemented it, though.

My understanding was that we need to do integration work on gnome-initial-setup and gnome-software, and that that was planned for F33. Is that right, @kalev ?

Yes, that's correct.

@kalev is away so we're assuming this won't happen for F33 - switching the milestone to F34.

I'd like to have this package renamed from fedora-workstation-repositories to fedora-thirdparty-repositories to make it more palatable to ship across any and all variants. I'm interested in shipping this in Fedora KDE as well, and I think other spins/editions might as well.

Renaming the package seems uncontroversial to me, as long as WG maintains control of included third-party repos.

I'd like to have this package renamed from fedora-workstation-repositories to fedora-thirdparty-repositories to make it more palatable to ship across any and all variants. I'm interested in shipping this in Fedora KDE as well, and I think other spins/editions might as well.

Thinking about it, this should probably be a separate issue...

Well, this has been approved. We never actually implemented it, though.

My understanding was that we need to do integration work on gnome-initial-setup and gnome-software, and that that was planned for F33. Is that right, @kalev ?

Kalev, are you still planning to work on this one?

@kalev looks like this ticket is approved and you previously volunteered to implement. Shall we aim for F34 or defer it to F35?

Since other people (like me) may have lost track of the current behavior, I did some testing in a fresh VM and wrote it up at:
https://hackmd.io/@owtaylor/fedora-third-party-repos

I don't have a good sense of what behavior we want here - but I'm pretty sure simply installing this package by default will not provide that. We also need to include the filtered flathub view from #108 when we specify our desired behavior.

Since other people (like me) may have lost track of the current behavior, I did some testing in a fresh VM and wrote it up at:
https://hackmd.io/@owtaylor/fedora-third-party-repos

Thanks for this, Owen! A few notes from my side below; I'm happy to add them to your pad or a separate document somewhere.

Aside from these specific points, one of the goals I have from the UX side is to simplify the overall model. The combination of disabled repo with enabled metadata is foreign to most users and I think that a model where the repos are simply either enabled or disabled would be far easier to understand.

Software Infobar

Originally the plan (at least from my perspective) was to have 3rd party repo enablement happen in initial setup (see above for the latest mockup). The infobar was just a fallback solution for cases where someone might not have gone through initial setup.

The main issues with the info bar is that you need to go to Software to see and enable it. Also, it doesn't look great and isn't a great place to explain what the 3rd party repos are.

About the link to the wiki, there are a couple of issues here that I'm aware of:

1. The wiki isn't a stable place to host information that we're pointing users to - that's #215
2. The content on that page isn't a good fit for end user documantation - it's verbose, technical, out of date, and it doesn't feel like it's specifically written with an end user audience in mind. It's been on my mind to try and rewrite it at some point.

Behavior with disabled repositories

I've never liked those "Enable Third-Party Repository?" dialogs and had hoped to remove them. They are confusing and surprising.

Repositories dialog

This is overdue a redesign and I'm waiting on developer involvement to get on with it. The upstream ticket for that is https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1166 .

As part of that design update, I was hoping to simplify the presentation of the 3rd party repos.

Thanks for this, Owen! A few notes from my side below; I'm happy to add them to your pad or a separate document somewhere.

Let's extend the single document... better something long than having too many separate places. (Feel free to add notes/links inline or as a separate section as seems appropriate.)

Aside from these specific points, one of the goals I have from the UX side is to simplify the overall model. The combination of disabled repo with enabled metadata is foreign to most users and I think that a model where the repos are simply either enabled or disabled would be far easier to understand.

100% agree that this is a confusing model. It's also not easily extensible to the Flatpak case where repositories can't be disabled - they can just be added and removed.

One idea is that we have a system-wide boolean maintained in, say /etc/fedora-repositories.conf and a script that maintains it and associated configuration: fedora-repositories --enable-third-party/--disable-third-party/--update, and then we hook that up to a switch in Software. If the user toggles it, other repositories update appropriately. There will be a certain amount of corner cases and complexity compared to the current model, but I don't think that's avoidable.

Software Infobar

Originally the plan (at least from my perspective) was to have 3rd party repo enablement happen in initial setup (see above for the latest mockup). The infobar was just a fallback solution for cases where someone might not have gone through initial setup.

We might still need the infobar temporarily to deal with upgrades - if we make fedora-workstation-repositories a mandatory part of Workstation, we're going to have no idea whether user opted in or out on upgrade, so we need a way to ask again without GNOME Initial Setup.

100% agree that this is a confusing model. It's also not easily extensible to the Flatpak case where repositories can't be disabled - they can just be added and removed.

The specific problem this is trying to solve is making sure third-party software can be requested properly (such as drivers and such) in a way that the dialog can be triggered to enable the repo properly.

This might actually be a failing for Flatpak too. It doesn't make sense that those kinds of knobs don't exist for Flatpak remotes.

100% agree that this is a confusing model. It's also not easily extensible to the Flatpak case where repositories can't be disabled - they can just be added and removed.

The specific problem this is trying to solve is making sure third-party software can be requested properly (such as drivers and such) in a way that the dialog can be triggered to enable the repo properly.

Can you give a specific example?

This might actually be a failing for Flatpak too. It doesn't make sense that those kinds of knobs don't exist for Flatpak remotes.

flatpak remote-add --disable and flatpak remote-modify flathub --disable/--enable actually exist. One missing piece here is that there's no way to have a .flatpakrepo file that specifies that the repo should be created disabled - but that could be added if necessary.

So it's really a matter of UI choice that GNOME Software offers "Remove" for Flatpak repositories but Disable/Enable for RPM repositories. This isn't entirely random:

• RPM repositories are normally packaged - offering to remove them is confusing, because they would just reappear on upgrade. Removing a package sometimes works, but there could be multiple repositories, the package might be required by something else, etc.

• Flatpak repositories are often added by the user. It would be weird if there was no way to remove a repository that you added.

Perhaps a) the Fedora Flatpak repository b) the proposed filtered Flathub repository should be considered built-in and should be enable/disable. Would need some mechanism for GNOME Software to know which was which.

100% agree that this is a confusing model. It's also not easily extensible to the Flatpak case where repositories can't be disabled - they can just be added and removed.

The specific problem this is trying to solve is making sure third-party software can be requested properly (such as drivers and such) in a way that the dialog can be triggered to enable the repo properly.

Can you give a specific example?

There were two examples when it was first designed:

• GStreamer codecs (OpenH264)
• Nvidia drivers

The former was only accessible if the metadata fetching was enabled so that the codec discovery stuff worked. We have since switched it to enabled by default so this is less of an issue.

The latter can have installation triggered by driver managers that know how to request drivers from modalias() Provides or AppStream metadata with modalias information. I packaged up linux-driver-management to allow GNOME Software to add support for actually doing this, but it never got done.

There's a trivial code example of how this could work with DNF in the ldm repo: https://github.com/solus-project/linux-driver-management/blob/master/examples/dnf-integration.py

This might actually be a failing for Flatpak too. It doesn't make sense that those kinds of knobs don't exist for Flatpak remotes.

flatpak remote-add --disable and flatpak remote-modify flathub --disable/--enable actually exist. One missing piece here is that there's no way to have a .flatpakrepo file that specifies that the repo should be created disabled - but that could be added if necessary.

So it's really a matter of UI choice that GNOME Software offers "Remove" for Flatpak repositories but Disable/Enable for RPM repositories. This isn't entirely random:

• RPM repositories are normally packaged - offering to remove them is confusing, because they would just reappear on upgrade. Removing a package sometimes works, but there could be multiple repositories, the package might be required by something else, etc.

• Flatpak repositories are often added by the user. It would be weird if there was no way to remove a repository that you added.

Perhaps a) the Fedora Flatpak repository b) the proposed filtered Flathub repository should be considered built-in and should be enable/disable. Would need some mechanism for GNOME Software to know which was which.

Yes. A concept of "vendor shipped" and "user configured" repositories should exist in Flatpak. There's also discussions going on about making this concept a thing in DNF too.

The latter can have installation triggered by driver managers that know how to request drivers from modalias() Provides or AppStream metadata with modalias information. I packaged up linux-driver-management to allow GNOME Software to add support for actually doing this, but it never got done.

If I'm following, the idea is that the first time you boot with an NVIDIA gpu (after install, after plugging one in) GNOME Software would suggest installing the NVIDIA binary drivers? This presumably works if the repository is enabled as well?

There's some amount of extra security against malicious repository updates (Supplements: gnome-shell?) by not having the repository enabled before the user explicitly installs something from it, but I tend to think that's outweighed by the shear weirdness of the "Enable" button for 3rd party software not actually enabling the repositories, and leaving the packages unavailable for 'dnf install', etc.

The latter can have installation triggered by driver managers that know how to request drivers from modalias() Provides or AppStream metadata with modalias information. I packaged up linux-driver-management to allow GNOME Software to add support for actually doing this, but it never got done.

If I'm following, the idea is that the first time you boot with an NVIDIA gpu (after install, after plugging one in) GNOME Software would suggest installing the NVIDIA binary drivers? This presumably works if the repository is enabled as well?

Basically, yes. The idea would be that it would propose it, and then if the user assents, it would seamlessly enable it, install it, configure it, and then prompt to reboot once things are set up so it can take effect.

One design question to consider here: presumably we want a way for users to opt into the 3rd party repos, and thereafter receive additional repos when we add them? I wonder how compatible this is with allowing users to have control over which of the 3rd party repos are enabled.

Draft change proposal: https://fedoraproject.org/wiki/Changes/Third_Party_Software_Mechanism

One design question to consider here: presumably we want a way for users to opt into the 3rd party repos, and thereafter receive additional repos when we add them? I wonder how compatible this is with allowing users to have control over which of the 3rd party repos are enabled.

There's some slight complexity and state-tracking in the backend, but in the end, I think we can remember which repositories we've already seen and only propagate the users preferences to newly added repositories, while leaving any repositories they've explicitly disabled, disabled.

Draft change proposal: https://fedoraproject.org/wiki/Changes/Third_Party_Software_Mechanism

I've now submitted this change proposal.

This was already discussed two weeks ago and awaiting Change approval.

Thanks for doing the change proposal, @otaylor ! How will the opt-in status relate to the status of each of the 3rd party repos? Do you imagine that it will be possible to have opt-in as true and only some of the repos enabled?

I'm wondering about how to represent this in UI terms.

[Sorry for the noise - just noticed the comment above.]

From an implementation point-of-view, it's hard to prevent the user from individually enabling/disabling the third-party repositories, since it's expected that users can do that by editing files in /etc/yum/repos.d directly. And I can see users wanting to do this at least occasionally - maybe you only want OSS third-party repositories, maybe you want to make your own judgements.

See also:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PMGOJ7NHSBRIORS7TZDSSCRR454QV5IY/

So at the backend level, I'd imagine that toggling the third-party status enables/disables everything, but if you leave it unchanged then it only affects newly installed third-party repositories.

I hope that doesn't present an insurmountable GUI challange... I could imagine something with [Enable all]/[Disable all] buttons.

There's also the issue that Flatpak repositories are Add/Remove and not enable/disable in the current GS repositories dialog. That could possibly be changed for "built-in" repositories like the Fedora repository or third-party repositories.

So at the backend level, I'd imagine that toggling the third-party status enables/disables everything, but if you leave it unchanged then it only affects newly installed third-party repositories.

If I'm understanding correctly, the issue there is that enabling/disabling the global 3rd party status could have unintended consequences - someone might want to enable new repos but not have every existing repo enabled, or they might want to have new repos disabled but keep some existing repos enabled.

In my mind enable/disable all isn't particularly important for the settings. Users will be able to enable all from initial setup and the info bar, and it's not a huge number of repos if they do need to toggle them all.

Perhaps something like this would work?

Landed some code for a configuration-file management tool:

Source: https://pagure.io/fedora-third-party/
Fedora package review request: https://bugzilla.redhat.com/show_bug.cgi?id=1989357

Not entirely finished (it needs better logging of what it's doing, and better error handling), but has a plausibly complete command line and docs, and seems to work.

Thanks @otaylor ! Links for GNOME integration work:

• gnome-initial-setup
• gnome-software

GNOME 41 UI freeze is 14 August - a little under 2 weeks from now.

This is the initial setup UI that Michael has landed:

https://gitlab.gnome.org/GNOME/gnome-initial-setup/uploads/d01e2155fbe5323ac474b6ff11eb8557/Screenshot_from_2021-08-02_14-02-35.png

Discussed this in today's meeting. GNOME UI freeze is close now; next steps:

• Owen to talk with Milan about what's needed to get the gnome-software integration done. A decision will need to be made about PolicyKit rules here; the consensus seemed to be that users should be prompted for their passwords if changing the repos.
• Allan to re-assess having an opt-in/opt-out switch in the gnome-software repository settings (otherwise there would be no way to opt out once opted in). The setting will need to communicate that it will only apply to new repos as they are added.
• Allan to check on the status of the addons category in the gnome-software development version. Is it still present? How does someone install the NVIDIA drivers now?
• Unassigned: Steam and PyCharm are currently missing app data. Someone needs to check on what we're doing for Chrome and reproduce for these two apps.
• All: testing to be done with rawhide and a VM. We should track the pieces we need to land in rawhide and test once they are in.

Some quick feedback with my upstream gnome-software co-maintainer hat on, although I’m not very familiar with Fedora’s processes so please ignore it if I’m off the mark here (I apologise if so).

Would it be possible to adjust the Fedora change proposal process (or whatever process is at work here) so that UI and feature changes are raised/discussed with upstream significantly more than a week before the upstream feature/UI freeze please? With a bit more notice, we could have planned resources for designing/implementing/reviewing/testing this feature rather than diverting resources to it at the last minute, away from other things. Thanks.

Would it be possible to adjust the Fedora change proposal process (or whatever process is at work here) so that UI and feature changes are raised/discussed with upstream significantly more than a week before the upstream feature/UI freeze please?

Hi Philip -

I think the Fedora process is largely OK here. The Fedora change process is mostly used for taking already done upstream changes and putting them into Fedora or alternatively for doing things that are very much Fedora-internal, so it doesn't put much emphasis on upstream communication. When upstream communication is clearly needed, it seems to happen, and is definitely something FESCO asks about in review

I was thinking of https://fedoraproject.org/wiki/Changes/Third_Party_Software_Mechanism as ta self-contained Fedora thing - but certainly it wouldn't have hurt to have filed an issue in GNOME gitlab to track it as something that was coming!

The problems here came from a number of factors:

• I didn't get Milan the backend code early enough for him to get a MR done earlier. Mostly just too many things on my plate. Sorry.
• This change fell into a gray area where the code is pretty Fedora specific but still upstream - so it wasn't clear that design discussion was needed with upstream maintainers.
• On both a design and code side, this intersected in a confusing way with the overall Repository redesign - and any upstream directed comments about this change were easily lost in the shuffle.

In any case, thanks for the feedback and I apologize for the situation!

fedora-third-party and fedora-flathub-remote packages are now built for F35 and Rawhide. Filed pull requests for fedora-workstation-repositories to make it use the fedora-third-party syste.

https://src.fedoraproject.org/rpms/fedora-workstation-repositories/pull-request/8
https://src.fedoraproject.org/rpms/fedora-workstation-repositories/pull-request/9

If someone wants to give those a quick look, that would be appreciated. Once that's built, the remaining steps for this and #108 are:

• fedora-workstation-repositories and fedora-flathub-remote dependencies of fedora-release-workstation
• make fedora-flathub-remote a dependency of fedora-release-silverblue, or add it to the OS definition otherwise
• enable the fedora-third-party-refresh onboot service for silverblue.

I've merged and built fedora-workstation-repositories for F35 and Rawhide.

make fedora-flathub-remote a dependency of fedora-release-silverblue, or add it to the OS definition otherwise
enable the fedora-third-party-refresh onboot service for silverblue.

Did these two get done?

I'm on SIlverblue 35 (rebased from 34) adn I can confirm that I do have fedora-flathub-remote package installed, but the service isn't enabled:

$ rpm -qa | grep flathub
fedora-flathub-remote-1-1.fc35.noarch
$ systemctl status fedora-third-party-refresh.service
○ fedora-third-party-refresh.service - Refresh Fedora Third-party Repositories
     Loaded: loaded (/usr/lib/systemd/system/fedora-third-party-refresh.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
       Docs: man:fedora-third-party(1)

This is now complete and released with Fedora Linux 35.