#108 Approve filtered view of flathub as third-party repo?
Opened a year ago by catanzaro. Modified 2 months ago

@kalev pointed out that we did not properly follow the third-party repo policy in https://src.fedoraproject.org/rpms/fedora-workstation-repositories/pull-request/7. In particular, from https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/#_repositories_with_non_free_libre_software:

"Non free software repositories must be approved by a active Fedora Working Group (for an edition), or FESCO (for all other deliverables)"

so we should either approve it, or not.

We're also violating the guidelines for tier-two flatpaks, https://fedoraproject.org/wiki/Workstation/Third_party_software_policies#Third_party_Flatpaks_.28Tier_Two.29, due to the use of the org.gnome.Platform runtime rather than org.fedoraproject runtime. If we want to keep Steam from flathub, then we should remove this rule.

Lastly, I notice we already have a separate repo specifically for Steam, rpmfusion-nonfree-steam.repo. If we want users installing Steam from flathub instead of rpmfusion, then we ought to remove that Steam repo. But at this point, I'm starting to wonder if maybe it's easier to just use the rpmfusion repo.


I'm +1 to adding Steam from flathub.

Although this brings up interesting questions: should we migrate existing users that are using steam from rpmfusion to steam from flathub? Should we remove rpmfusion steam from 3rd party repos now that we have flathub steam?

I think we should migrate users whenever possible, to avoid fragmenting the user experience.

+1 to adding Steam from flathub
+1 to removing the 3rd party tier-two rule; or patch it such that the rule requires approved runtimes in which case I'm +1 to the org.gnome.Platform runtime

Also I asked mclasen and he says the point of using flathub is to make Steam work on Silverblue, not possible with the version from rpmfusion.

I also said that I don't think we want to create a parallel universe where everything that is available on flathub gets duplicated as a (inferior-quality, higher-overhead) fedora rpm. That would be counterproductive.

Oh, we also have a rule that each repo should only install one thing. The point of the rule is to ensure new things are not added to the repo that could entail legal risk. But the purpose of the filters is to avoid this problem.

Aside: We'll probably also want to add the OpenH264 extension to our filters.

I also said that I don't think we want to create a parallel universe where everything that is available on flathub gets duplicated as a (inferior-quality, higher-overhead) fedora rpm. That would be counterproductive.

I have rarely heard anyone say that Flathub maintenance is a positive experience. One of the reasons I refused to take over the Lugaru flatpak on Flathub (as upstream of Lugaru) is because the development, testing, and maintainer workflows for flatpaks suck.

Fedora RPMs are of higher quality than Flatpaks, in general. People understand how to make them, they're tested more, and integrate well with the system.

So, no, if you suggest eliminating RPMs for Flatpaks, I'll be against any proposal that demands that.

Please refrain from pointless comments. "Higher quality" is devoid of meaning, unless you spell out what aspects you are looking at.

Nobody is suggesting eliminating rpm.

Please refrain from pointless comments. "Higher quality" is devoid of meaning, unless you spell out what aspects you are looking at.
Nobody is suggesting eliminating rpm.

Then don't call RPMs "inferior-quality". And you were.

Then don't call RPMs "inferior-quality". And you were.

if was talking about a hypothetical future. You were spouting generalisations and hearsay

We're discussing moving from RPM to flatpak for one particular application. It's not a big deal, so no need for exaggerations.

Anyway, I've reverted the change since after discussion at today's WG meeting we identified concerns about (a) possible quality issues with the Steam flatpak, (b) possible user experience issues with upgrading from filtered flathub to full flathub, and (c) questions about whether there should be some sort of migration from RPM to flatpak (I think probably not). I like flathub so I've tried to make clear that this revert may be temporary and is mainly intended to allow for further discussion. Action items from today's meeting:

  • Everyone to test and identify any critical issues with Steam, PyCharm and NVIDEA from Flathub; add the results to this ticket (including: ngompa to list issues with the Steam flatpak)
  • aday and kalev to provide more details on what the gnome-software UX for a filtered Flathub would look like
  • mcatanzaro to revert the commit (done)

I will leave the meeting keyword on this ticket since I expect we should complete these action items quickly and be ready to continue discussion soon enough.

BTW the vote was (+9,0,-1)

Everyone to test and identify any critical issues with Steam, PyCharm and NVIDEA from Flathub; add the results to this ticket (including: ngompa to list issues with the Steam flatpak)

@ngompa, could you take some time to look into this, please?

aday and kalev to provide more details on what the gnome-software UX for a filtered Flathub would look like

So my understanding of the problem here is that we have a filter disabling everything except Steam in the flathub.flatpakrepo file. Now say the user wants to enable all of flathub. How does this work? Does the filter prevent the user from manually enabling all of flathub? Or will it be seen as two separate remotes?

So my understanding of the problem here is that we have a filter disabling everything except Steam in the flathub.flatpakrepo file. Now say the user wants to enable all of flathub. How does this work? Does the filter prevent the user from manually enabling all of flathub? Or will it be seen as two separate remotes?

It works exactly as before - you install the flatpakref file from the flathub website. Flatpak is smart enough to recognize this situation and avoids creating a separate remote. Instead, it removes the filter from the existing flathub remote.

OK. Looking at our action items:

Everyone to test and identify any critical issues with Steam, PyCharm and NVIDEA from Flathub; add the results to this ticket (including: ngompa to list issues with the Steam flatpak)

This hasn't happened. Absent specific concerns, it seems reasonable to assume the software provided by Flathub is good. @ngompa, any comments regarding Steam specifically?

aday and kalev to provide more details on what the gnome-software UX for a filtered Flathub would look like

Matthias's comment should address most concerns here. I suppose the only remaining point would be to see what it looks like in the Software Repositories dialog when a remote is installed with this filter. Does it look different from a normal installation of flathub? Is there some UI indication that the repo is filtered?

Final concern: we have a guideline "Third party applications are strongly recommended to use the official Fedora Flatpak runtime to avoid unneeded runtime proliferation, and to preserve users' disk space." It's a SHOULD, not a MUST, but it would be weird to violate our own guidelines. We should discuss altering this guideline to accommodate use of Flathub. (That said, even if we allow only Fedora and Flathub runtimes, there's significant potential for runtime proliferation issues even with just freedesktop-sdk, GNOME, and KDE runtimes.)

Everyone to test and identify any critical issues with Steam, PyCharm and NVIDEA from Flathub

I missed this. Is there a quick and dirty test case somewhere that I can follow? I haven't ever used Steam so I don't know what I'm comparing or reporting on.

there's significant potential for runtime proliferation issues

I don't fully understand what this proliferation means: multiple origins for an otherwise identical versioned runtime? org.gnome.Platform/x86_64/3.30 could be provided by multiple origins, no deduplication?

I don't fully understand what this proliferation means: multiple origins for an otherwise identical versioned runtime? org.gnome.Platform/x86_64/3.30 could be provided by multiple origins, no deduplication?

No, the problem would be entirely separate runtimes. Currently our third-party software guidelines strongly recommend using the Fedora runtime to avoid dragging in non-Fedora runtimes, including the GNOME runtime. That might have made sense at the time we drafted the guidelines, but it seems questionable today whether that's really the strategy we want to pursue. (Clearly, Matthias doesn't like it. :)

Is the Fedora runtime ostensibly a superset of runtimes that includes the GNOME runtime? If not can it? Should it? And would that reduce at least the local problem of runtime proliferation?

I have org.fedoraproject.Platform/x86_64/f29 which is 1G, but then also multiple freedesktop, GNOME, and KDE runtimes totaling over 6G. There are three versions of the GNOME runtime, I'm not sure if behind the scenes these are effectively deduplicated already. When I run a Btrfs dedup on /var/lib/flatpak, nothing gets deduped.

I don't have a problem with non-Fedora runtimes per se. I'm seeing ~7GiB just in runtimes, and am sensitive to excess usage, in particular on Workstation with default partitioning on which there's no storage pool sharing and resizing is non-trivial.

No, the Fedora runtime is completely unrelated to the GNOME runtime. The Fedora runtime is based on Fedora packages. The GNOME runtime is distribution-agnostic and based on freedesktop-sdk.

We cannot plausibly build Fedora flatpaks based on the GNOME runtime because they would bear no relation to Fedora packages; it would make more sense to just give up on the Fedora packages and use flatpaks published by Flathub instead (which might be a reasonable choice for flatpaks that are available on Flathub). In contrast, we have automation to facilitate the creation of Fedora flatpaks based on the Fedora runtime.

There are three versions of the GNOME runtime, I'm not sure if behind the scenes these are effectively deduplicated already.

They're already deduplicated by ostree, so I doubt there's much room for improvement here. Having only one version of the same runtime installed would help, but that might be too much to expect as app developers have full control of what version they depend on. Running flatpak remove --unused occasionally might also help; I think by default it leaves stale runtimes around, which isn't great.

Metadata Update from @chrismurphy:
- Issue untagged with: meeting

a year ago

@mclasen - during yesterday's call I think you suggested that it's already possible to use a filtered version of Flathub. Can you fill us in on what the next steps could be for this issue?

I think that we will need to get PRs mentioned in https://teams.fedoraproject.org/project/silverblue/us/82?kanban-status=37 (and its subtasks) merged.

I think that we will need to get PRs mentioned in https://teams.fedoraproject.org/project/silverblue/us/82?kanban-status=37 (and its subtasks) merged.

My memory of the discussion for these issues is a bit fuzzy... those tickets are proposing a whitelist which is maintained on the Fedora side. That's a bit different from what's being suggested in this ticket, which is a filtered view (implying that the different categories of software would be determined on the Flathub side, rather than the Fedora side).

Did the WG decide in the past that a whitelist is the way to go? Obviously it's going to be less flexible than using a filter provided by Flathub.

If we do go for the whitelist option, the proposal here is that the WG itself should maintain the whitelist, including approving apps. I guess that, if that's the way we want to go, we'll need to flesh out the process and the inclusion requirements. That's a policy task for someone, and I assume will require authorization from Fedora Council?

My memory of the discussion for these issues is a bit fuzzy... those tickets are proposing a whitelist which is maintained on the Fedora side. That's a bit different from what's being suggested in this ticket, which is a filtered view (implying that the different categories of software would be determined on the Flathub side, rather than the Fedora side).

No, the "filtered view" is literally a whitelist maintained by Fedora in fedora-workstation-repositories. It is https://src.fedoraproject.org/rpms/fedora-workstation-repositories/pull-request/7. Please, read the first comment....

Did the WG decide in the past that a whitelist is the way to go? Obviously it's going to be less flexible than using a filter provided by Flathub.

No, we never decided anything. I reverted the change because Kalev objected that we did this without discussing it and formally approving it first. Again, see the first comment above.

If we do go for the whitelist option, the proposal here is that the WG itself should maintain the whitelist, including approving apps. I guess that, if that's the way we want to go, we'll need to flesh out the process and the inclusion requirements. That's a policy task for someone, and I assume will require authorization from Fedora Council?

No, we don't need any special authorization to do this. As long as Workstation WG believes the software complies with our legal requirements, we can include it. Again, per the first comment, the only policy problem here is that enabling flathub is not allowed per our requirements for third-party flatpaks. We can change that rule whenever we want.

Sounds like this might be ready for meeting discussion? Is it possible to get a draft/proposed rule change? Maybe even several variations?

Sounds like this might be ready for meeting discussion? Is it possible to get a draft/proposed rule change? Maybe even several variations?

I'd be interested in hearing about the high level goals and constraints before we get stuck into policies and proposals. The original proposal was to add a relatively limited number of apps to fedora-workstation-repositories, but then there's a whole world of apps in flathub that we would really like to make available. Is there a way to bridge that gap?

My memory of the discussion for these issues is a bit fuzzy... those tickets are proposing a whitelist which is maintained on the Fedora side. That's a bit different from what's being suggested in this ticket, which is a filtered view (implying that the different categories of software would be determined on the Flathub side, rather than the Fedora side).

No, the "filtered view" is literally a whitelist maintained by Fedora in fedora-workstation-repositories. It is https://src.fedoraproject.org/rpms/fedora-workstation-repositories/pull-request/7. Please, read the first comment....

Sorry, the report didn't mean much to me on first reading. I didn't realise that the PR had commentary with it.

While the original PR is for a limited whitelist, we have previously discussed using a filtered view, using metadata (or even separate repos) that is maintained by Flathub. It would still be good to know if that idea is still in play, or whether it has been rejected (and if so, on what grounds).

...

If we do go for the whitelist option, the proposal here is that the WG itself should maintain the whitelist ...

No, we don't need any special authorization to do this. As long as Workstation WG believes the software complies with our legal requirements, we can include it.

Are you sure? On what basis do we have the authorization to do this currently? My reading of the 3rd party repo policy is that it requires repos to be approved by Fedora Legal, and that each repo only contains one app.

Hm, I was looking at our third-party software policies, which says: "The Fedora working groups will evaluate if a proposed addition or provider poses a significant risk, and if in doubt confer with Fedora Legal for advice." That strongly implies we have the authority to do this ourselves. It seems we have two different conflicting policies for third-party software inclusion.

Hm, I was looking at our third-party software policies

Do you know the status of that page? I've asked around on several occasions and no one has been able to to tell me what its role is. In the end I assumed that it was an old working draft, because the official policy that was approved by Council is kept with the fesco-docs.

Can you ask cschalle? He was taking care of the third party policy side and should know. We always deferred all the decisions to him basically. The Workstation WG has approved third party repos in the past without going through FESCo so I believe we should have the powers to approve more.

Can you ask cschalle?

I think I've tried that in the past, but yes - I'll ask again!

However, whatever he says, I do think that we ought to act in accordance with the rules set out by Council/FESCo. Reading through those again, they are pretty clear that 3rd party repos shouldn't include "diverse pieces of software".

I suspect that we are OK to approve our own 3rd party repos, although the policy actually includes contradictory statements on that point (it would be good to resolve that). Relevant lines below:

Lines 22 & 23:

  • Third party repositories that host diverse pieces of software (a repository like Fedora before it became a Red Hat community project, for instance) cannot be searched or enabled. This is because it would simply be too much work for Fedora Legal to audit such a repository.
  • Repositories that enable a specific piece of free software may be shipped if the repo file has the enabled=0 and enabled_metadata=0 settings. They must be approved by both FESCo and Fedora Legal first.

Line 37:

  • Non free software repositories must be approved by a active Fedora Working Group (for an edition), or FESCO (for all other deliverables) and are subject to the same critera as the section above on other free software repositories (ie, permission may be revoked, repositories with many different applications will be rejected as too difficult to police, etc)

Do you know the status of that page? I've asked around on several occasions and no one has been able to to tell me what its role is. In the end I assumed that it was an old working draft, because the official policy that was approved by Council is kept with the fesco-docs.

That page is not a draft; it is an actual effective policy that applies to Fedora Workstation. If you care to delve into the wiki history, it actually used to have a big draft warning at the top, which was removed at some point... it also predates the name "flatpak" as the guidelines originally used the term "xdg-app," remember that? :D

Anyway, this page predates our use of Pagure to track what we're doing, and also predates the FESCo third party repo policy. We should probably, at the very least, update it to reflect the existence of the FESCo policy to avoid confusion, since there seem to be some points that conflict with FESCo's policy, and the FESCo policy overrides ours. But note the scope of the two policies is different, since the FESCo policy sets rules for what software WGs may include, whereas our policy sets rules for third-party software vendors to get their software included (in fedora-workstation-repos) if it is unable to be packaged normally in Fedora. So the policies are not duplicitive.

Our original policy strongly discourages hosting multiple applications in the same repo, but this guidance is specific to RPM repos and was clearly not intended to apply to flatpaks. It's also not an outright ban:

A yum repository may contain multiple applications. However, third parties are strongly recommended to ship their software in single application repositories as it will greatly increase chances of repository getting accepted for inlusion. Also doing this minimizes the risk of "collateral damage" if one piece of software must be de-listed from Fedora temporarily or permanently for legal or other reasons. A yum repository is a hard requirement for RPM packaged applications to be considered. Repositories that mix applications with different purposes are also strongly discouraged, for instance contains a mixture of desktop and server software. In the end which repositories are acceptable is left to the discretion of the working groups based on an evalution of technical and legal risks posed by a given repository, but as a general rule the easiest path to inclusion is doing single application repositories.

So we have two issues to resolve: (a) the FESCo policy clearly bans repositories that contain multiple applications, so we would need to try to change that, and (b) our own policy strongly discourages use of non-Fedora flatpak runtimes.

There is actually a little debate on an old draft version of the page between Christian and myself as to whether we should allow upstream GNOME flatpaks or require that flatpaks be built specially for Fedora:

Michael:

It's ambiguous what the "official" runtime is here. We surely want third-party apps to use upstream GNOME runtimes to avoid runtime proliferation.

Christian:

no we do not, for a variety of reasons, but the most screaming one being that the upstream GNOME carries no support promises and unless a very dedicated and large volunteer community arises to support it there is no chance it will become supported. The upstream GNOME one should be seen as the runtime from Git master option, which is probably mostly useful for 1st party modules in GNOME for development purposes.

Michael:

This probably requires further discussion outside the wiki. We agree to encourage xdg-app as a solution for cross-distro app development. If we're also going to encourage upstreams to depend on downstream Fedora runtimes, that makes this a much tougher sell to third party developers.

This was four years ago. It's not clear whether that's still the approach we really want to take today, given that flathub has been quite successful.

Do you know the status of that page? I've asked around on several occasions and no one has been able to to tell me what its role is. In the end I assumed that it was an old working draft, because the official policy that was approved by Council is kept with the fesco-docs.

That page is not a draft; it is an actual effective policy that applies to Fedora Workstation. If you care to delve into the wiki history, it actually used to have a big draft warning at the top

I find that page to be really confusing; it isn't clear what its role is and it has the same name as the FESCo policy. Also the history says that it's official, but there's no details on who approved it or when.

I suspect that the approval came from Fedora Council in this ticket. It's hard to be sure, because the ticket itself doesn't say exactly what was being approved, and the dates don't exactly align, but they are somewhat close and @uraeus 's reference to "the wiki page" is suggestive.

Anyway, I'll suggest some updates to that page, just to try and clarify the situation. I might need some help with that!

...

But note the scope of the two policies is different, since the FESCo policy sets rules for what software WGs may include, whereas our policy sets rules for third-party software vendors to get their software included (in fedora-workstation-repos) if it is unable to be packaged normally in Fedora. So the policies are not duplicitive.

Thanks, I hadn't realised that.

So we have two issues to resolve: (a) the FESCo policy clearly bans repositories that contain multiple applications, so we would need to try to change that, and

I would hope that this is a simple change to get approved by Council - a whitelist seems to be in keeping with the logic and spirit of the existing policy.

(b) our own policy strongly discourages use of non-Fedora flatpak runtimes.

Right, we should resolve that.

I would add the comment I made above as a further issue to resolve: (c) the FESCo policy is contradictory as to whether working groups can approve their own third party repositories. Since it states both:

"Repositories that enable a specific piece of free software may be shipped if the repo file has the enabled=0 and enabled_metadata=0 settings. They must be approved by both FESCo and Fedora Legal first."

And:

"Non free software repositories must be approved by a active Fedora Working Group (for an edition), or FESCO (for all other deliverables)".

The best thing might be for us to present Fedora Council with a batch of policy changes that they can review and approve en masse.

I've spent most of today rewriting the 3rd party software repositories page. This was the only way for me to fully understand what it is. :laughing:

Essentially, the wiki page is an extended set of requirements and guidelines, which supplement the official FESCo policy. I think the main audience is working groups, in how they can use the FESCo policy, although it does include a some information for FESCo itself and for maintainers of software repos.

Since the wiki page covers all editions and spins, the workstation working group wiki clearly isn't the right place for it. I'd recommend adding it to fesco-docs, either alongside or merged into the other fesco policy. Otherwise it's just going to continue getting ignored.

BTW after talking with Christian, he agrees that this rule is no longer appropriate:

"Third party Flatpaks (tier two) applications are strongly recommended to use the official Fedora Flatpak runtime to avoid unneeded runtime proliferation, and to preserve users' disk space."

I suggest we just drop it.

I suggest we just drop it.

Done.

This commit merges the worksation policy from the wiki page into the main FESCo docs. I can present it to Fedora Council to see if they will accept it.

I can also prepare a subsequent commit which amends the "diverse pieces of software" clause to permit whitelisting. However, before I do, it would be good to get guidance from the WG as to whether this is the approach it wants to pursue.

Metadata Update from @aday:
- Issue tagged with: meeting

8 months ago

Metadata Update from @chrismurphy:
- Issue untagged with: meeting

8 months ago

I've prepared some amendments to the FESCo-maintained policy here, and the following is a draft for the ticket that I'd like to present.

I believe that these two changes would clear the policy obstacle to us implementing the whitelist.

Draft council ticket

Hi Council,

Thanks again for your help with issue #289. The Workstation Working Group is continuing its work around 3rd party repos and, as a result, have two policy amendments that we would like to present. (These can both by found in this PR.)

1. Housekeeping

For some reason we seem to have two competing 3rd party repo policies (the first is in the FESCo docs, the second is on the workstation wiki pages). We've been unable to reconstruct the exact history of both, but it does seems that they have both been approved for use.

The version on the workstation wiki page is also much more detailed and comprehensive. We are therefore proposing to merge the two policies.

Some considerations that you ought to be aware of here:

  • The existing FESCo policy seems to specify that working groups can approve 3rd party repos containing non-free software, but not repos that contain free software. It is unclear whether this was intentional or not and, as a result, the update changes the policy to give working groups the ability to approve 3rd party repos that contain both free and non-free software.
  • The change applies the recent decision about metadata enablement to all types of repos covered under the policy, including Coprs.
  • The policy on the workstation wiki also covers the types of repos that can be used as the main repos of an edition, the intention being to enable working groups to provide Moby images and Flatpaks out of the box. Since these aren't 3rd party repositories, these sections have been removed from the policy. My suggestion would be to have a separate policy elsewhere to cover what can and can't be used as an edition's primary repositories.

2. App whitelisting and "diverse repos"

The workstation working group would like to be able to include certain applications from Flathub in its 3rd party repos, and we'd like to do this by maintaining our own whitelist of Flathub apps to make available.

Our understanding is that the existing FESCo policy prevents this, because of the following clause:

"Third party repositories that host diverse pieces of software (a repository like Fedora before it became a Red Hat community project, for instance) cannot be searched or enabled."

We would therefore like to change that clause to read as follows:

"Working groups and SIGs should maintain close control over the software that is made available through third party repositories, in order to prevent unvetted software being made available to Fedora users. As part of this, third party repositories should be managed in such a way that Fedora Legal can easily audit them at any time. This implies that third party repositories should be limited to including small numbers of packages, or that measures should be put in place to limit which packages are made available from a particular repository."

We believe that this change remains true to the original intent of the policy, while giving us some additional flexibility in how to implement it.

The FESCo docs version includes some logical inconsistencies. For example, it specifies that working groups can approve 3rd party repos containing non-free software, but not repos that only contain free software.

Why is that a logical inconsistency? I would say that FESCo deliberately worded it like this to make sure that free software that's allowed by Fedora policies goes into Fedora package collection, and the rest that's not allowed in Fedora (non-free) is then provided by third party repositories.

The FESCo docs version includes some logical inconsistencies. For example, it specifies that working groups can approve 3rd party repos containing non-free software, but not repos that only contain free software.

Why is that a logical inconsistency? I would say that FESCo deliberately worded it like this to make sure that free software that's allowed by Fedora policies goes into Fedora package collection, and the rest that's not allowed in Fedora (non-free) is then provided by third party repositories.

The policy sections on free and non-free software look like they had different authors or emerged at different times - they don't feel like they're part of the same document, so I was reading a bit between the lines here. But it's also not too hard to imagine cases where it's more convenient to host a free app as a third party repo, and it seemed odd for WGs to have less freedom about including free software than non-free.

But you're right that it's better not to assume the intent here - I can reword that paragraph to ask for clarification rather than assuming that the FESCo policy is disjointed.

A straw man proposal for a process for adding apps to the whitelist:

  • The WG decides to propose an app for inclusion
  • A ticket is created for the app. The ticket is also advertised on fedora-desktop. People can:
    • +1 the ticket, meaning that they've tested it and it has passed a certain quality standard that has been set out
    • comment with any issues that they have encountered with the app (ideally containing a link to a separate issue report)
  • An app is approved:
    • if the ticket has been open for at least two weeks, and
    • if the ticket has at least 3 +1's, and
    • if any issues have been reported, the WG has decided that they aren't blockers

Metadata Update from @chrismurphy:
- Issue tagged with: meeting

8 months ago

Metadata Update from @chrismurphy:
- Issue untagged with: meeting

8 months ago

Policy changes have been submitted to Fedora Council here

Metadata Update from @aday:
- Issue set to the milestone: Fedora 33

7 months ago

The changes being proposed by FESCo are likely going to require more discussion, so this is very unlikely to land in F33. I'll switch the target to F34.

Metadata Update from @aday:
- Issue set to the milestone: Fedora 34 (was: Fedora 33)

5 months ago

The updated 3rd party repos policy has now landed (MR, current master). The new version should be compatible with a filtered view of Flathub.

@otaylor is going to come up with a list of Flathub apps to include in the 3rd party repos, to be reviewed by the working group.

Metadata Update from @aday:
- Issue assigned to otaylor

2 months ago

Login to comment on this ticket.

Metadata