devel-announce June 2022

devel-announce@lists.fedoraproject.org

10 participants
29 discussions

Planned Outage - Bodhi upgrade - 2022-06-09 09:00 UTC
by Mark O'Brien 08 Jun '22

08 Jun '22

Hi all, Apologies for the very delayed notice on this. I should have sent this mail a lot earlier. TL;DR there will be an outage of Bodhi tomorrow morning EU time for some upgrades Planned Outage - Bodhi upgrade - 2022-06-09 09:00 UTC There will be an outage starting at 2022-06-09 09:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2022-06-09 09:00 UTC' Reason for outage: Swtich to OpenID connect for authentication and more... Affected Services: Bodhi and any service which relies on it Ticket Link: https://pagure.io/fedora-infrastructure/issue/10754 Please join #fedora-admin or #fedora-noc on irc.libera.chat or add comments to the ticket for this outage above. Thanks, Mark

1 0

Fedora 34 is EOL
by Tomas Hrcka 07 Jun '22

07 Jun '22

Hello all, As of the 7th of June 2022, Fedora 34 has reached its end of life for updates and support. No further updates, including security updates, will be available for Fedora 34. All the updates that are currently in testing won't get pushed to stable. Fedora 35 will continue to receive updates until approximately one month after the release of Fedora 37. The maintenance schedule of Fedora releases is documented on the Fedora Project wiki [0]. The Fedora Project wiki also contains instructions [1] on how to upgrade from a previous release of Fedora to a version receiving updates. Tomas Hrcka [0] https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedu… [1] https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/

1 0

Fedora 34 is going EOL in one day.
by Tomas Hrcka 06 Jun '22

06 Jun '22

Hello all, Fedora 34 will go end of life for updates and support on 2022-06-07 No further updates, including security updates, will be available for Fedora 34 after the said date. All the updates of Fedora 34 being pushed to stable will be stopped as well. Fedora 35 will continue to receive updates until approximately one month after the release of Fedora 37. The maintenance schedule of Fedora releases is documented on the Fedora Project wiki [0]. The Fedora Project wiki also contains instructions [1] on how to upgrade from a previous release of Fedora to a version receiving updates. Regards, Fedora Release Engineering [0] https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedu… [1]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades -- Tomas Hrcka role: CPE Team - Senior Software Engineer fas: humaton freenode: jednorozec

1 0

F37 proposal: Erlang 25 (Self-Contained Change proposal)
by Ben Cotton 03 Jun '22

03 Jun '22

https://fedoraproject.org/wiki/Changes/Erlang_25 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 == Update Erlang/OTP to version 25. == Owner == * Name: [[User:Peter|Peter Lemenkov]], [[SIGs/Erlang|Fedora Erlang SIG]], [[User:bowlofeggs|Randy Barlow]], [[User:jcline|Jeremy Cline]] * Email: lemenkov(a)gmail.com, erlang(a)lists.fedoraproject.org, bowlofeggs(a)fedoraproject.org, jcline(a)fedoraproject.org == Detailed Description == Upgrade Erlang to version 25 which brings a lot of changes. Just a few highlights [https://www.erlang.org/blog/my-otp-25-highlights/ from many]: * [https://www.erlang.org/blog/parallel-signal-sending-optimization/ The Many-to-One Parallel Signal Sending Optimization]. * [https://www.erlang.org/blog/type-based-optimizations-in-the-jit/ Type-Based Optimizations in the JIT]. * New 'maybe' operator. * The JIT now supports the AArch64 (ARM64) architecture. * Better support for perf and gdb. * Better error reporting in some cases. Aside from this, we plan to further improve quality of Erlang and related packages. These are shortcomings we want to address: * Finish switching to rebar3 as a main build tool and deprecate rebar2. ** Improve [[User:Peter/Erlang_Packaging_Guidelines|Erlang Packaging Guidelines]] according to this switch and promote it as the official guideline. * Every daemon written in Erlang has its own logging solution which doesn't use neither syslog nor Journald. We should start switching them to unified logger. * We should allow D-Bus API via [https://github.com/lizenn/erlang-dbus erlang-dbus] library or any other recent implementations.. * SELinux rules for main Erlang applications (Ejabberd, CouchDB, RabbitMQ) are still outdated or missing. == Benefit to Fedora == Fedora users, both developers and end-users, will have visible benefits from using Fedora-provided packages. Namely: * Improved scalability and robustness. * Much easier developing and debugging. == Scope == * Proposal owners: ** [https://bugzilla.redhat.com/show_bug.cgi?id=2055490 Upgrade Erlang to the latest version (25.0)]. ** Every Erlang daemon's systemd unit should require epmd.socket. ** Upgrade outdated packages: *** {{package|riak|Riak}} **** {{package|riak|Riak}} has has been retired. We have to re-add it back. *** {{package|ejabberd|Ejabberd}} *** {{package|rabbitmq-server|RabbitMQ}}. *** {{package|couchdb|CouchDB}} **** {{package|riak|CouchDB}} has has been retired. We have to re-add it back. ** {{package|erlang-rebar3|rebar3}} ** Package GDB macros for easier coredump debugging (see also [https://bugzilla.redhat.com/show_bug.cgi?id=663253 this ticket]). * Other developers: N/A * Release engineering: TBA * Policies and guidelines: ** We should promote officially [[User:Peter/Erlang_Packaging_Guidelines|Erlang Packaging Guidelines]]. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == * Binaries compiled with Erlang 22 and older are no longer compatible. == How To Test == * Ensure that high-grade Erlang applications are still working: {| border="1" |- | '''Name''' || '''Tested''' |- | {{package|couchdb}} || {{no}} (package was retired :( ) |- | {{package|ejabberd}} || {{no}} |- | {{package|elixir}} || {{no}} |- | {{package|rabbitmq-server}} || {{no}} |- | {{package|riak}} || {{no}} (package was retired :( ) |- | {{package|wings}} || {{no}} |} * Collect feedback from volunteers regarding their experience with this Erlang/OTP version == User Experience == Users will get more robust, scalable, and fast Erlang applications. == Dependencies == The following packages must be rebuilt: NIF-libraries. == Contingency Plan == * Contingency mechanism: None necessary. Instead of falling back to the previous version we should fix existing packages in order to help the Community. We should also monitor upstream development process for potentially discovered issues and proactively apply patches (as we already did with [[Features/Erlang_R14|Erlang R14]], [[Features/Erlang_R15|Erlang R15]], [[Features/Erlang_R16|Erlang R16]], [[Changes/BetterErlangSupport|Erlang 17]], [[Changes/Erlang_18|Erlang 18]], [[Changes/Erlang_19|Erlang 19]], [[Changes/Erlang_20|Erlang 20]], [[Changes/Erlang_21|Erlang 21]], [[Changes/Erlang_22|Erlang 22]], [[Changes/Erlang_23|Erlang 23]], and [[Changes/Erlang_24|Erlang 24]]). It should be noted that this change consists from an independent or loosely coupled smaller changes. If we fail to deliver some changes in time, we should reschedule these exact changes to the future Fedora release while keeping already implemented ones. * Contingency deadline: N/A * Blocks release? N/A * Blocks product? N/A == Documentation == * [https://www.erlang.org/news/157 Erlang/OTP 25.0 release notes] == Release Notes == Erlang/OTP 25.0 is available in Fedora 37. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F37 proposal: Supplement of Server distributables by a KVM VM disk image (Self-Contained Change proposal)
by Ben Cotton 02 Jun '22

02 Jun '22

https://fedoraproject.org/wiki/Changes/Supplement-server-by-kvm-vm-image 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 == Virtualization has long been a steadily growing use case of Fedora Server Edition, but it is still time consuming and tedious for the system administrator to create a Fedora Server VM. Supplementing the downloads by a KVM VM image remedies the deficiency. == Owner == * Name: [[User:pboy| Peter Boy on behalf of Server WG]] * Email: pboy(a)uni-bremen.de == Detailed Description == The creation of the VM disk image, uses the same kickstart files and installation groups as the standard full installation, except of course for the hardware-specific items. The image is optimized for KVM. That way, the VM resembles a default server installation as closely as possible. All administrative tools are available reliably from the beginning, all administrative routines and helps (scripts) can be used in the same way. All application services work in the identical way. A default VM installation takes 1-2 minutes instead of about 30 mins. == Feedback == The change proposal is based on an extensive discussion of the server WG and has become part of its work program. For example, the server documentation on virtualization has already been significantly expanded in parallel and will continue to be supplemented and updated on an ongoing basis. This is a response to the importance of the topic. == Benefit to Fedora == Significantly improves usability for Fedora Server Edition administrators when deploying a Fedora Server Edtion VM. It thus makes Fedora Server Edition more attractive, especially for new users without extensive experience with Fedora. It thus helps to expand our user base. Fedora finally provides an installation path for a Fedora Server VM that is built entirely on Fedora Resources, subject to Fedora quality control, and compliant with Fedora principles. Until now, if a system administrator has to install a VM preferable without the hassles of a full default installation, we could only recommend third party binary blob (e.g. virt-builder), which is a violation of our own core principles. In addition, the third party products do not provide a 'Fedora Server Edition', but their own different concept and vision of a server, under the name Fedora Server. == Scope == * Proposal owners: A kickstart file for ImageFactory is completed and locally tested. * Other developers: n/a * Release engineering: [https://pagure.io/releng/issues #10768] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: n/a == Upgrade/compatibility impact == none == How To Test == Basically, the same test procedures as for the full install apply. 1. Install a Fedora Server Edition including virtualization, follow the Server documentation 2. Import the Fedora Server disk image following the Server documentation (staging), either using Cockpit or cli virt-install 3. Use the VM with your intendend server applications. == User Experience == Users (system administrators) will have a VM install method available, which saves them a lot of time and efforts. == Dependencies == none == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), No == Documentation == N/A (not a System Wide Change) Fedora Server documentation is available. == Release Notes == TBD -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F37 proposal: LLVM 15 (Self-Contained Change proposal)
by Ben Cotton 02 Jun '22

02 Jun '22

https://fedoraproject.org/wiki/Changes/LLVM-15 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 == Update all llvm sub-projects in Fedora Linux to version 15. == Owner == * Name: [[User:tstellar| Tom Stellard]] * Email: <tstellar(a)redhat.com> == Detailed Description == All llvm sub-projects in Fedora will be updated to version 15, and there will be a soname version change for the llvm libraries. Compatibility packages clang14 and llvm14 will be added to ensure that packages that currently depend on clang and llvm version 14 libraries will continue to work. == Benefit to Fedora == New features and bug fixes provided by the latest version of LLVM. == Scope == * Proposal owners: ** Review existing llvm and clang compatibility packages and orphan any packages that are no longer used. ** Build release candidates into @fedora-llvm-team/llvm15 COPR. ** Build final release (Sep 2022) into Rawhide and F37 branches. * Other developers: ** Maintainers of packages that depend on clang-libs or llvm-libs will need to update their spec files to depend on the clang14 and llvm14 compatibility packages if they want to rebuild their package and it does not work with LLVM 15 yet. The key point here is that spec file changes are only needed if a package is going to be rebuilt after LLVM 15 is added to Fedora. The compatibility packages will ensure that already built packages continue to work. * Release engineering: [https://pagure.io/releng/issues/10820 #10820] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == This change should not impact upgradeability. == How To Test == The CI tests for the llvm sub-packages in Fedora will be used to catch regressions that might be potentially introduced by the update to LLVM 15. == User Experience == == Dependencies == This change can be made without updating any other packages. However, as mention before, packages that need to use LLVM 14 will need to update their spec file on their first rebuild after this change. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Contingency mechanism: (What to do? Who will do it?): If there are major problems with LLVM 15, the compatibility package provide a way for other packages to continue using LLVM 14. * Contingency deadline: Final Freeze * Blocks release? No == Documentation == Release notes will be added for this change. == Release Notes == LLVM sub-projects in Fedora have been updated to version 15: llvm clang lld lldb compiler-rt libomp llvm-test-suite libcxx libcxxabi python-lit flang mlir polly libclc llvm-unwind -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)
by Ben Cotton 02 Jun '22

02 Jun '22

https://fedoraproject.org/wiki/Changes/RPMMacrosForBuildFlags 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 == Create a corresponding macro for each compiler flag in the redhat-rpm-config macro file and create "extra flag" macros to make it easier for packages to add and remove compiler flags. == Owner == * Name: [[User:tstellar| Tom Stellard]] * Email: <tstellar(a)redhat.com> == Detailed Description == The macros file in the redhat-rpm-config package contains a list of default compiler flags for packages to use when compiling C, C++, and Fortran packages. There is currently no standard way to remove or add to the set of default flags. Most packages use a combination of echo and sed to remove unwanted flags or add new ones. Some examples: compiler-rt: [https://src.fedoraproject.org/rpms/compiler-rt/blob/rawhide/f/compiler-rt.s… global optflags %(echo %{optflags} -D_DEFAULT_SOURCE)] julia: [https://src.fedoraproject.org/rpms/julia/blob/rawhide/f/julia.spec#_267 %global optflags %(echo %{optflags} | sed 's/-Wp,-D_GLIBCXX_ASSERTIONS //')] This change will add new macros which will make it easier for packages to add and remove their own compiler flags. This strategy is already used to some extent with feature macros like %{_lto_cflags}, %{_hardening_cflags}, etc, but these new macros will give packagers even more fine-grained control over the options. The proposed macros for adding new flags are: %_pkg_extra_cflags %_pkg_extra_cxxflags %_pkg_extra_fflags %_pkg_extra_ldflags These will be added to %{build_cflags}, %{build_cxxflags}, %{build_fflags}, and %{build_ldflags} respectively to allow packges to add their own flags to the default list: e.g. %build_cflags %{optflags} %{_pkg_extra_cflags} The proposed new macros to represent existing flags are: %_flag_fstack_protector_strong -fstack-protector-strong %_flag_z_now -Wl,-z,now %_flag_z_defs -Wl,-z,defs %_flag_flto_auto -flto=auto %_flag_ffat_lto_objects -ffat-lto-objects %_flag_o -O2 %_flag_f_exceptions -fexceptions %_flag_g -g %_flag_grecord_gcc_switches -grecord-gcc-switches %_flag_pipe -pipe %_flag_wall -Wall %_flag_werror_format_security -Werror=format-security %_flag_fortify_source -Wp,-D_FORTIFY_SOURCE=2 %_flag_glibcxx_assertions -Wp,-D_GLIBCXX_ASSERTIONS %_flag_asynchronous_unwind_tables -fasynchronous-unwind-tables %_flag_fstack_clash_protection -fstack-clash-protection %_flag_fcf_protection -fcf-protection %_flag_mbranch_protection_standard -mbranch-protection=standard With these new macros, the examples from above could be re-written as: compiler-rt: %global _pkg_extra_cflags -D_DEFAULT_SOURCE julia: %global _flag_glibcxx_assertions %{nil} For more details see the [https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/0ee9a8… Prototype Implementation]. In addition to adding these new macros, the packaging guidelines will be updated to require that all new flags added to redhat-rpm-config have their own RPM macro. == Benefit to Fedora == * It will provide a standard way to disable existing compiler flags or enable new ones that is more simple and robust than the existing echo + sed solution. * It will make it easier to determine which packages disable or add compiler flags by doing a simple grep of the spec files. * It will make it easier for toolchain developers to experiment with adding new flags to the distribution as this can be done with a simple macro definition instead of patching redhat-rpm-config. == Scope == * Proposal owners: ** Proposal owners will update the redhat-rpm-config package and add the new macros. ** Proposal owners will test the changes to ensure that the correct flags are still being used. * Other developers: ** Other developers may, but are not required to, update their packages to use the new macros. * Release engineering: [https://pagure.io/releng/issues/10819 #10819] * Policies and guidelines: ** The Fedora packaging policy will be updated to require that new flags added to redhat-rpm-config come with their own RPM macro. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == None. == How To Test == * This can be tested by inspecting the value of the %{build_cflags}, %{build_cxxflags}, %{build_fflags}, and %{build_ldflags} and ensuring they are the same before and after the change. * This can be tested by modifying some of the new macros in a spec file and ensuring that the changes appear in the appropriate macro mentioned above. == User Experience == This is a change for developers and will have no impact to the user experience. == Dependencies == None. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Change owner will revert the update to redhat-rpm-config. * Contingency deadline: Mass Rebuild * Blocks release? N/A (not a System Wide Change), No == Documentation == None. == Release Notes == None. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F37 proposal: Fallback Hostname (System-Wide Change proposal)
by Ben Cotton 02 Jun '22

02 Jun '22

https://fedoraproject.org/wiki/Changes/FallbackHostname 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 == This proposal is for the fallback hostname for server like variants of Fedora to use `localhost` as the fallback hostname. == Owner == * Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS) * Email: dustymabe(a)redhat.com * Name: [[User:davdunc| David Duncan]] (Fedora Cloud) * Email: davdunc(a)gmail.com * Name: [[User:pwhalen| Paul Whalen]] (Fedora IoT) * Email: pwhalen(a)redhat.com * Name: [[User:salimma| Michel Alexandre Salim]] (Fedora Server) * Email: michel(a)michel-slm.name * Name: [[User:ngompa| Neal Gompa]] (Fedora Workstation/KDE) * Email: ngompa13(a)gmail.com == Detailed Description == In Fedora 33 the default fallback hostname was changed from `localhost` to `fedora` for Fedora Linux instances that didn't get the hostname set in any other way (i.e. it's the fallback if it's not set anywhere else). This change came in a systemd update and was never proposed as a change in Fedora itself. The enablement upstream was in https://github.com/systemd/systemd/pull/5175 and the BZ requesting the change in Fedora was https://bugzilla.redhat.com/show_bug.cgi?id=1392925. The original reasoning being that `localhost` is a bad hostname for auto-discovery protocols (think `avahi`) that are useful for more desktop applications. Unfortunately, this caused issues because setting the hostname via reverse DNS lookups (via NetworkManager) stopped working along with breaking third party tools that set the hostname. The NetworkManager problem was subsequently fixed, but it still remains that a lot of third party software will check to see if an instance's hostname is "unset" by checking the current hostname against the string "localhost". Additionally it appears this change will never be picked up by Fedora's primary downstream in CentOS/RHEL (see https://src.fedoraproject.org/rpms/systemd/c/13d1341b108a24d13f5922054307b5…) The proposal here is to enable variants of Fedora Linux to configure their default/fallback hostname and to set the default for variants targetting servers (Cloud, CoreOS, IoT, Server) to `localhost`. == Benefit to Fedora == With this change Fedora's server-like variants will become more compatible with third party tools that expect a hostname of `localhost` means the system is unconfigured. It also will mean system administrator's will see `localhost` and assume the hostname is unconfigured. == Scope == * Proposal owners: The feature owners will update the systemd compile time switch for fallback hostname back to `localhost`. The `fedora-release` package will be updated such that the Fedora Server, IoT, Cloud, and CoreOS editions will use `localhost` as the fallback hostname. All other variants of Fedora (the ones that target desktop/laptop uses) will default to `fedora` as the fallback hostname. The proposed changes are a relatively small amount of a work. * Other developers: For any variants other than Cloud, CoreOS, IoT, and Server they will see no change. Work with QA to verify other editions continue to have a fallback hostname of `fedora`. For Cloud, CoreOS, IoT, and Server the default fallback hostname would be `localhost`. * Release engineering: No changes needed for release engineering. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == There will be NO upgrade impact to systems where: * An admin statically set the hostname * A hostname was provided to a system via DHCP * A hostname was found for a system via reverse DNS lookup In the case where none of the above are true for a system (i.e. a fallback hostname will be used) the following upgrade impact will be observed: * Fedora Cloud: No impact. A booted Fedora Cloud 36 instance has `/etc/hostname` written by `cloud-init` on first boot. * Fedora CoreOS: No impact. Already using `localhost` as fallback hostname. * Fedora IoT: Some impact. The fallback hostname will change from `fedora` to `localhost` after upgrade. * Fedora Server: Some impact. The fallback hostname will change from `fedora` to `localhost` after upgrade. For Fedora IoT and Fedora Server we will announce the change and encourage users to statically set a hostname for their machines if they don't want the change in behavior. == How To Test == Boot an instance of the flavor of Fedora you are testing in an environment where there is no DHCP hostname provided and no answer to a reverse DNS lookup for the instance IP. Run `hostnamectl hostname` and verify that it matches expectation. For Fedora Cloud, CoreOS, IoT, Server it should be `localhost`. For all others it should be `fedora`. == User Experience == For Cloud, CoreOS, IoT and Server users will notice intances now default to `localhost` if a hostname is not provided to an instance by any other means. For all other variants of Fedora there will be no change. == Dependencies == There will be changes to the `systemd` and `fedora-release` packages for this change. == Contingency Plan == * Contingency mechanism: Revert the pull requests to the `systemd` and `fedora-release` packages. * Contingency deadline: Final Freeze * Blocks release? Yes == Documentation == The fallback hostname has now changed to `localhost` for the Cloud, CoreOS, IoT, and Server variants of Fedora. == Release Notes == The fallback hostname has now changed for the Cloud, CoreOS, IoT, and Server editions of Fedora to `localhost`. The fallback hostname is the hostname that is set if the hostname cannot be determined by any other mechanism (statically set, DHCP, or reverse DNS). This change was done in order to conform to the common expectation that a hostname of `localhost` on a system means the hostname is "unset". -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Take the Fedora Annual Contributor Survey 2022
by Aleksandra Fedorova 02 Jun '22

02 Jun '22

Hello, everyone, Please participate in the Fedora Annual Contributor Survey 2022! * https://fedoraproject.limequery.com/2022 The survey is anonymous, it has 44 questions targeting Fedora contributors of all kinds and asks about your default choices of applications and services. This is the second run of the survey. The questions are the same as last year with more variants added according to the data we have collected. We will compare answers for this year with the previous year results. At the end of the survey you will get the claim link for the badge. For questions and feedback please refer to the forum thread: * https://discussion.fedoraproject.org/t/we-want-to-hear-from-you-take-the-fe… Thank you for your contribution! -- Aleksandra Fedorova bookwar on Matrix/IRC

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce June 2022