F38 proposal: Unfiltered Flathub (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/UnfilteredFlathub Note that I am processing this proposal past the deadline because 1. I think it could reasonably be considered a Self-Contained Change proposal and 2. the reasons outlined by Mattias in another thread: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/PKUEM64L7FDGQBPRKZTHF5EF5FTLVSXG/ This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Fedora Workstation's existing [https://docs.fedoraproject.org/en-US/workstation-working-group/third-party-repos/ third party repo feature] allows users to enable a selection of software repos that are hosted by external organizations. This selection has included a filtered version of Flathub since F35, which provides access to a small number of Flathub apps. This change would remove the filtering from our Flathub offering, so that users can enable a complete version of Flathub using the third party repositories feature. In the graphical software manager app, Flathub packages will only be selected by default when no Fedora package is available. == Owner == * Name: Workstation WG * Email: mcla...@redhat.com == Detailed Description == Since F35, Fedora has included a Flatpak repo definition for Flathub in the fedora-flathub-remote package. This Flathub remote can be used by those who enable third-party software repositories through either GNOME Initial Setup or GNOME Software. Users who do not opt in do not see any content from Flathub. The current Flathub remote is filtered by an allowlist, to only make a limited subset of software from Flathub available. The unfiltered Flathub change has two parts: # Remove the allowlist from the Flatpak remote, so that when a user opts in, they gain access to all Flathub content and not just a small selection. # Adjust GNOME Software so that it uses the following priority order when deciding which package to offer by default: ## Fedora Flatpaks ## RPMs ## Flathub Flatpaks This will mean that, when using the graphical software manager, Flathub Flatpaks will only be selected by default when there is no Fedora Flatpak or RPM. Other details: * In GNOME Software, users will continue to be able to manually select a different source for individual applications. * The filtering mechanism will remain in place, and it will be possible to reinstate a filter via a package update, should the need arise in the future. * It has been indicated that it is legally acceptable for us to remove the filtering from the Flathub remote that we make available for users to opt into. * The UI for enabling the third party repositories clearly states that they contain proprietary software. * GNOME Software shows information about whether apps are open source or proprietary, so that users can decide whether they want to install them or not. == Feedback == A previous version of this proposal was rejected by FESCo for Fedora 37. It has subsequently been modified to address the concerns raised: * GNOME Software will prefer packages that have been through the Fedora packaging process, over those that have not. * For developer tools that do not work well in a sandbox, there will be no Fedora Flatpak, and the RPM will be preferred over the Flathub Flatpak. Some other questions and concerns that were raised in the previous discussion: === Who owns and runs Flathub? === Flathub is owned and run by [https://foundation.gnome.org/ the GNOME Foundation], which is a 501c(3) organization registered in the USA. (The GNOME Foundation [https://foundation.gnome.org/legal-and-trademarks/ owns the Flathub trademark], and employs one of the sysadmins who works on Flathub.) As a non-profit, the GNOME Foundation is required to fulfill a charitable purpose. This is set out in its IRS registration, which states that the organization's mission is "broadening access to technology through the development and distribution of... usable free computer desktop software". The GNOME Foundation is governed by its Board of Directors, which is elected by contributors to the GNOME project. Plans exist to create additional governance around Flathub itself, so that other desktops and projects have a formal role in the running of the Flathub service. === Isn't Flathub full of repackaged binaries? === At present, around 10% of the apps on Flathub have been repackaged from another format. These other formats include distro packages and tarballs, as well as binaries. (The previous figure was 12% - the analysis for this can be read [https://blogs.gnome.org/wjjt/2022/06/14/how-many-flathub-apps-reuse-other-package-formats/ here].) Flathub prefers that apps be built from source, and if sources are available this is what it is expected to be used. Repackaging is only used when sources aren't available,
Re: Automation of Fedora SCM requests
Most of the issues are resolved now. There is one remaining ticket [0] that is returning 500 on branch creation. I will continue investigation on this ticket tomorrow. I'm sorry for the rough start. On behalf of CPE Team, Michal [0] - https://pagure.io/releng/fedora-scm-requests/issue/50370 On 10. 01. 23 13:52, Michal Konecny wrote: Hi everyone, after deployment we had some issues with API tokens for src.fedorapoject.org and pagure.io. Those issues are now solved. Only one issue remains and that is missing list of epel9 packages on https://infrastructure.fedoraproject.org/repo/json We are currently working on that. All the epel9 branch requests will fail right now, we will reprocess them once this is fixed. On behalf of CPE Team, Michal On 10. 01. 23 12:26, Michal Konecny wrote: Hi everyone, this automation is now in place and new SCM requests will be processed automatically. If you find any issue with the automation, please report it to toddlers issue tracker [0]. On behalf of CPE Team, Michal [0] - https://pagure.io/fedora-infra/toddlers/issues On 08. 12. 22 11:10, Michal Konecny wrote: Hello everyone, for some time CPE (Community Platform Engineering) team is working on automating Fedora SCM requests [0]. The automation is currently live on staging. You can see the output (closed tickets) in Fedora SCM requests staging repo [1]. The automation is done using a plugin in toddlers [2]. We have a documentation [3] for the new toddler, if you want to know more about it. There is also a ticket [4] tracking this work. We plan to deploy this in production on *10th January 2023*, after that all the Fedora SCM request will be processed automatically and it will ping correct people if the manual intervention is needed. This will not change anything in user workflow, it will just make the job of Fedora Release Engineering Team easier and let them focus on other things. On behalf of CPE Team, Michal [0] - https://pagure.io/releng/fedora-scm-requests [1] - https://stg.pagure.io/releng/fedora-scm-requests [2] - https://pagure.io/fedora-infra/toddlers [3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs [4] - https://pagure.io/releng/issue/9274 ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Automation of Fedora SCM requests
Hi everyone, after deployment we had some issues with API tokens for src.fedorapoject.org and pagure.io. Those issues are now solved. Only one issue remains and that is missing list of epel9 packages on https://infrastructure.fedoraproject.org/repo/json We are currently working on that. All the epel9 branch requests will fail right now, we will reprocess them once this is fixed. On behalf of CPE Team, Michal On 10. 01. 23 12:26, Michal Konecny wrote: Hi everyone, this automation is now in place and new SCM requests will be processed automatically. If you find any issue with the automation, please report it to toddlers issue tracker [0]. On behalf of CPE Team, Michal [0] - https://pagure.io/fedora-infra/toddlers/issues On 08. 12. 22 11:10, Michal Konecny wrote: Hello everyone, for some time CPE (Community Platform Engineering) team is working on automating Fedora SCM requests [0]. The automation is currently live on staging. You can see the output (closed tickets) in Fedora SCM requests staging repo [1]. The automation is done using a plugin in toddlers [2]. We have a documentation [3] for the new toddler, if you want to know more about it. There is also a ticket [4] tracking this work. We plan to deploy this in production on *10th January 2023*, after that all the Fedora SCM request will be processed automatically and it will ping correct people if the manual intervention is needed. This will not change anything in user workflow, it will just make the job of Fedora Release Engineering Team easier and let them focus on other things. On behalf of CPE Team, Michal [0] - https://pagure.io/releng/fedora-scm-requests [1] - https://stg.pagure.io/releng/fedora-scm-requests [2] - https://pagure.io/fedora-infra/toddlers [3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs [4] - https://pagure.io/releng/issue/9274 ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Automation of Fedora SCM requests
Hi everyone, this automation is now in place and new SCM requests will be processed automatically. If you find any issue with the automation, please report it to toddlers issue tracker [0]. On behalf of CPE Team, Michal [0] - https://pagure.io/fedora-infra/toddlers/issues On 08. 12. 22 11:10, Michal Konecny wrote: Hello everyone, for some time CPE (Community Platform Engineering) team is working on automating Fedora SCM requests [0]. The automation is currently live on staging. You can see the output (closed tickets) in Fedora SCM requests staging repo [1]. The automation is done using a plugin in toddlers [2]. We have a documentation [3] for the new toddler, if you want to know more about it. There is also a ticket [4] tracking this work. We plan to deploy this in production on *10th January 2023*, after that all the Fedora SCM request will be processed automatically and it will ping correct people if the manual intervention is needed. This will not change anything in user workflow, it will just make the job of Fedora Release Engineering Team easier and let them focus on other things. On behalf of CPE Team, Michal [0] - https://pagure.io/releng/fedora-scm-requests [1] - https://stg.pagure.io/releng/fedora-scm-requests [2] - https://pagure.io/fedora-infra/toddlers [3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs [4] - https://pagure.io/releng/issue/9274 ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
