https://fedoraproject.org/wiki/Changes/ManPagesRuRetirement
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 ==
Retiring man-pages-ru because it is already part of the man-pages-l10n.
== Owner ==
* Name: [[User:ljavorsk| Lukas Javorsky]]
* Email: ljavorsk(a)redhat.com
== Detailed Description ==
Upstream (man-pages-l10n) has integrated Russian translations for
man-pages. It means we no longer need to have a specific
(man-pages-ru) package for it.
[https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/commit/37b44f5a…
Upstream commit containing the change]
The plan is simple:
1) Deprecate man-pages-ru package
2) Enable 'ru' translations for man-pages-l10n (temporary disabled due
to conflicts). [https://src.fedoraproject.org/rpms/man-pages-l10n/c/00a88c237e1fd7cdef9c526…
Commit disabling it]
Also add Obsolete and Provides for man-pages-ru package.
== Feedback ==
Early feedback from the community is positive, the feedback is located
in this ([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
Devel list announce])
== Benefit to Fedora ==
Fedora shouldn't maintain a redundant package. This change would make
it easier for the maintainer as well as for the packages that requires
man-pages-l10n and man-pages-ru.
== Scope ==
* Proposal owners: Package man-pages-ru will be retired, and the
man-pages-l10n will contain the Russian translations.
* Other developers: Change the names of their BuildRequires/Requires
accordingly.
* Release engineering: No action required
* 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 ==
When following the plan in Detailed Description there will be no need
for manual action. Everything will be handled by the automated dnf
upgrade.
== How To Test ==
== User Experience ==
== Dependencies ==
List of the packages from Fedora 39
=== man-pages-ru ===
dnf repoquery --whatrequires man-pages-ru | pkgname
<empty>
dnf repoquery --whatrequires '/usr/share/man/ru/*' | pkgname
<empty>
== Contingency Plan ==
* Contingency mechanism: Remove the man-pages-l10n build with Russian
translation enabled. Revert deprecation of the man-pages-ru package.
* Contingency deadline: Beta freeze
* Blocks release? No
''NOTE: If we don't finish this change by the deadline, it is possible
to just complete this change with the next release.''
== Documentation ==
[https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/commit/37b44f5a…
Upstream issue]
[https://bugzilla.redhat.com/show_bug.cgi?id=2163421 Bugzilla tracker]
[https://sourceforge.net/p/man-pages-ru/discussion/1102373/thread/7dda92a232/
man-pages-l10n upstream discussion with man-pages-ru upstream about
this]
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/mkosi-initrd
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 ==
`mkosi-initrd` is an alternative builder for initrds.
It will be packaged in Fedora, so that users can use it to build
initrds locally.
A `kernel-install` plugin will be provided to build the initrd when a
kernel package is installed.
As a stretch goal, initrds will be build in koji and delivered via rpm packages.
As a further stretch goal, pre-built initrds will be used in Unified
Kernel Images that can be delivered via rpm packages.
Only a subset of installation types will be supported.
== Owner ==
* Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Name: [[User:lnykryn| Lukáš Nykrýn ]]
* Name: [[User:Daandemeyer| Daan De Meyer]]
* Email: zbyszek - at - in.waw.pl, lnykryn - at - redhat.com,
daandemeyer - at - fb.com
== Detailed Description ==
The process by which we create initrds is complicated and inefficient.
Initrds contain duplicate functionality and require a lot of maintainer effort.
The aim of this proposal is to introduce a vastly simplified mechanism
of initrd creation and simplified initrd contents.
The `mkosi-initrd` project is a set of config files for `mkosi`.
`mkosi` is a program to build operating system images from system packages.
An initrd is built by invoking `mkosi` with the config provided by
`mkosi-initrd`.
Instead of building initrds by scraping the file system and figuring
out dependencies again,
existing packages and normal package installation via `dnf`/`rpm` is
used to populate the initrd.
This also means that the package manager is responsible for satisfying
dependencies.
At runtime, `systemd` is responsible for setting up the execution
environment and invoking programs.
Currently, initrds built in this way are bigger than initrds built by dracut.
They also have limited functionality:
many common types of systems work just fine, but more exotic
configurations are not supported.
See [[#Scope|Scope]] below for a list of known good/bad features.
The goal of this change is to provide an ''alternative'' mechanism.
If the feedback is positive, we may consider using initrds built with
`mkosi-initrd` as default in certain scenarios.
There are no plans to remove `dracut` in the foreseeable future.
This means that for any case not supported or not working well,
`dracut` remains a natural fallback.
In this way this change is similar to
[[Changes/Unified_Kernel_Support_Phase_1]],
as it provides a preview of a new technology as an alternative to the
current established approach.
== Feedback ==
== Benefit to Fedora ==
Current initrd generation with `dracut` is showing its age.
As upstream packages evolve,
repeating the dependency resolution in `dracut` is a constant drain of
maintainer time.
Our `dracut` initrds are already using `systemd`.
But `systemd` is constantly evolving and adding new functionality
related to early boot:
decryption of disks, access to secrets, new configuration mechanisms,
state checks and boot counting.
More and more, `dracut` runtime scripting is a thin wrapper around `systemd`.
We have two job queues: the `dracut` initqueue, and the `systemd` job queue.
This duplication makes everything harder, both during preparation and
at runtime, for little benefit.
The design principle of the new approach is to remove duplicate functionality:
* package `Requires` replace dracut module dependency logic and
automatic installation of libraries based on `ldd` output
* `systemd` job management replaces the remainder of `dracut` runtime
* the environment in the initrd is just a normal linux system (albeit
on a temporary root fs)
* normal package contents replace special scripts crafted for the initrd
Generally, the new scheme requires very little new stuff.
We reuse things that are already available (and used):
`dnf` and `rpm`,
packages for all stuff that is used in the initrd,
`systemd`,
special systemd units for the initrd.
The new component is a mechanism that builds the initrd out of packages.
But it is a relatively simple step that requires very little maintenance.
The biggest part of the initial work is the creation of package lists
to install in the initrd,
and adjusting packages to to function correctly in the initrd and not
pull in unnecessary dependencies.
Afterwards, there might be occasional maintenance related to bugs or
package splits.
Initrds built with `mkosi-initrd` should be fully reproducible (in the
sense of reproducible builds).
The work done in packages has external benefits:
package minimization automatically benefits other "small" installations.
== Scope ==
* Proposal owners:
** package `mkosi-initrd`
([https://copr.fedorainfracloud.org/coprs/zbyszek/mkosi-initrd/builds/
copr], review-request
https://bugzilla.redhat.com/show_bug.cgi?id=2189633)
** verify (and fix if necessary) `mkosi-initrd`/`systemd`/other
packages to work with:
*** root on a plain partition
*** root on LVM2
*** root on LUKS
*** root on RAID
*** root on NFS
*** hibernation
** provide a `kernel-install` plugin that builds an initrd locally
** provide a `kernel-install` plugin that combines this initrd with a
kernel binary into a Unified Kernel Image locally
** make dracut not interfere with mkosi-initrd (merge
https://github.com/dracutdevs/dracut/pull/1825 or carry downstream
patch)
** work with koji developers to allow `mkosi-initrd` to run in koji
(stretch goal 1). This requires changing koji to allow access to
downloaded rpms during build.
** add a `mkosi-initrd-initrd` (name TBD) package that builds a set of
subpackages with initrds (stretch goal 2).
(Out of scope: support for root on iSCSI is not planned currently.
Our experiments with iSCSI show that the existing tooling is a bunch
of terrible scripts that don't work at all outside of dracut.)
More items may be added to Scope or listed as not planned based on feedback.
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
** koji developers: help with the rpms-in-buildroot functionality and
** koji maintainers and releng: deploy changes in koji in Fedora infra
** anyone: Install the new packages to opt-in into testing the new initrds.
* Release engineering:
* 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 is new functionality that will only impact people who opt-in.
== How To Test ==
* Right now:
** enable the copr and install `mkosi-initrd` (see
[https://github.com/systemd/mkosi-initrd/#mkosi-initrd--build-initrd-images-…
instructions])
** adjust configuration:<pre>echo 'initrd_generator=mkosi-initrd'
>>/etc/kernel/install.conf # Until
https://github.com/dracutdevs/dracut/pull/1825 is merged mkdir -p
/etc/kernel/install.d ln -s /dev/null
/etc/kernel/install.d/50-dracut.install</pre>
** Upgrade or reinstall kernel package and reboot
* After `mkosi-initrd` has an official build:
** disable the copr and update to the distro package
** Upgrade or reinstall kernel package and reboot
* After stretch goal 2:
** Install `mkosi-initrd-initrd-<variant>`
** Upgrade or reinstall kernel package and reboot
== User Experience ==
Ideally, there should be no visible change for users.
Obviously, when text logs are shown the console, the output is a bit different.
After stretch goals 2, installation will be quicker.
== Dependencies ==
Support for UKIs in grub2 was implemented in
[[Changes/Unified_Kernel_Support_Phase_1]],
but the support for UKIs in grub2 was not merged.
This support is a requirement for people who want to use mkosi-initrd
UKIs with grub2.
== Contingency Plan ==
* Contingency mechanism: Postpone introduction of features to a later
release. If it turns out that initrds are faulty, users who installed
them will need to manually switch back to dracut initrds.
* Contingency deadline: Any time.
* Blocks release? No.
== Documentation ==
https://github.com/systemd/mkosi-initrd/blob/main/docs/fedora.md
== Release Notes ==
Simplified initrds built with `mkosi-initrd` are available for testing.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/F39-Lazarus-repackaging
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 ==
Split the `lazarus` package (the Lazarus IDE for Free Pascal) into
several sub-packages (built from the same spec file) and enable
building the Lazarus Component Library for multiple widget sets,
instead of just the default GTK2.
== Owner ==
* Name: [[User:suve|Artur Frenszek-Iwicki]]
* Email: <fedora(a)svgames.pl>
== Detailed Description ==
The `lazarus` package will be split into multiple packages:
* `lazarus-doc` - documentation
* `lazarus-ide` - the IDE itself
* `lazarus-lcl` - base package for the LCL (Lazarus Component
Library), containing common LCL parts
* `lazarus-lcl-nogui` - components for building non-graphical applications
* `lazarus-lcl-gtk` - components for building programs using the GTK2
widget library
* `lazarus-tools` - command-line tools shipped with Lazarus, e.g. `lazbuild`
The `lazarus` package will become a metapackage - it will not contain
any files itself, instead pulling in all the packages mentioned above.
Several new packages will also be introduced:
* `lazarus-lcl-gtk3` - support for building programs using the GTK3
widget library
* `lazarus-lcl-qt` - ditto, for Qt4
* `lazarus-lcl-qt5` - ditto, for Qt5
== Benefit to Fedora ==
Currently, Lazarus in Fedora only supports building programs with the
GTK2 widget set. With this change, Lazarus will gain support for
additional widget sets, allowing users to build their applications
using GTK3, Qt4 and Qt5.
Maintainers of packages depending on Lazarus can switch from
BuildRequiring `lazarus` to the following set:
* `lazarus-lcl-nogui` (may not be needed, depending on the program)
* `lazarus-lcl-gtk2` (or a different widget set, if the maintainer so wishes)
* `lazarus-tools`
This minimal package set is about ~60MiB smaller than the current
Lazarus package. This should make builds slightly faster.
== Scope ==
* Proposal owners:
** Edit `lazarus.spec` as required and rebuild the package, preferably
before the Mass Rebuild.
* Other developers: No action required.
* Release engineering: No action required.
* 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 ==
When upgrading Fedora 39, users who have the `lazarus` package
installed should see the following sub-packages pulled in during the
process:
* `lazarus-doc`
* `lazarus-ide`
* `lazarus-lcl`
* `lazarus-lcl-nogui`
* `lazarus-lcl-gtk2`
* `lazarus-tools`
This set of packages should provide the same files and functionality
as the current monolithic `lazarus` package.
== How To Test ==
A copr repository has been created where users can test out the
modified package:
[https://copr.fedorainfracloud.org/coprs/suve/lazarus-split/
copr/suve/lazarus-split].
== User Experience ==
For users not interested in different widget sets, this Change should
not affect their experience. Those wanting to build their programs
using GTK3, Qt4 or Qt5 will gain the ability to do so.
== Dependencies ==
None.
== Contingency Plan ==
Worst case scenario - give up, revert to an old version of
`lazarus.spec` and rebuild the package.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
The `lazarus` package has been split into multiple sub-packages. Apart
from GTK2, the IDE now supports building programs using the GTK3, Qt4
and Qt5 widget sets - available by installing `lazarus-lcl-*`
packages.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/perl5.38
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 ==
A new ''perl 5.38'' version brings a lot of changes done over a year
of development. Perl 5.38 will be released in May 20th 2023. See
[https://metacpan.org/release/SHAY/perl-5.37.11/view/pod/perldelta.pod
perldelta for 5.37.11] for more details about new release.
== Owner ==
* Name: [[User:Jplesnik| Jitka Plesníková]], [[User:Mspacek| Michal
Josef Špaček]]
* Email: <jplesnik(a)redhat.com>, <mspacek(a)redhat.com>
== Current status ==
=== Completed Items ===
=== Items in Progress ===
=== Items to Be Done ===
* Get dedicated build-root from rel-engs (''f39-perl'')
* Upstream to release Perl 5.38
* Define perl_bootstrap in perl-srpm-macros
* Rebase perl to 5.38.0
* Rebuild all dual-lived packages (83) - otherwise dnf recommends
--skip-broken and fails
* Rebuild packages needed for minimal build-root
* Rebuild packages needed for building source packages from git repository
* Rebuild packages requiring ''libperl.so'' or versioned
''perl(MODULE_COMPAT)'': Use Fedora::Rebuild dependency solver
* Undefine perl_bootstrap
* Rebuild packages having perl_bootstrap condition in spec file (XX packages)
* Rebuild all updated packages
* [https://jplesnik.fedorapeople.org/5.38/ Final lists of results]
* Merge dedicated build-root to rawhide and remove the dedicated one by rel-engs
* Synchronize packages upgraded in ''f39'' build root
* Rebuild Perl packages: 0 of 600 done (0 %)
* Failed packages (0):
* Rebuild Fedora modules: 0 of 0 (0 %)
* Create module perl:5.38 and rebuild dependencies
== Detailed Description ==
New perl is released every year and updates containing mainly bug
fixes follow during the year. The 5.38.0 version is stable release
this year.
== Benefit to Fedora ==
Up-to-date and latest perl release will be delivered to Fedora users.
== Scope ==
Every Perl package will be rebuilt in a dedicated ''f39-perl''
build-root against perl 5.38.0 and then if no major problem emerges
the packages will be merged back to ''f39'' build-root.
* Proposal owners: New perl and all packages requiring ''libperl.so''
or versioned ''perl(MODULE_COMPAT)'' will be rebuilt into ''f39-perl''
build-root.
* Other developers: Owners of packages that fail to rebuild, mainly
perl-sig users, will be asked using Bugzilla to fix or remove their
packages from the distribution.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Release engineers will be asked for new ''f39-perl'' build-root
inheriting from ''f39'' build-root. After successful finishing the
rebuild, they will be asked to merge ''f39-perl'' packages back to
''f39'' build-root.
* 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 ==
Vast majority of functionality will be preserved. Only the packages
that failed to build against perl 5.38 will be removed from the
distribution. That will require to remove those packages from the
existing systems otherwise a package manager will encounter
unsatisfied dependencies. The developers in Perl language are advised
to install ''perl-doc'' and ''perl-debugger'' packages.
== How To Test ==
Try upgrading from Fedora 38 to 39. Try some Perl application to
verify they work as expected. Try embedded perl in
[https://src.fedoraproject.org/rpms/openldap slapd] or
[https://src.fedoraproject.org/rpms/net-snmp snmpd].
== User Experience ==
There should not be any remarkable change in user experience. With the
exception that previously locally installed modules with a CPAN
clients will need a reinstallation.
== Dependencies ==
There is more than 3500 packages depending on perl. It is the first
rebuild where we will rebuild only all dual-lived packages and
packages which require ''libperl.so'' or versioned
''perl(MODULE_COMPAT)''. It means only about 600 packages needs to
rebuild. Most of them are expected not to break. Finishing this change
can be endangered only by critical changes in a toolchain.
''noarch'' packages don't need to be rebuilt now.
== Contingency Plan ==
* Contingency mechanism: If we find perl 5.38 is not suitable for
Fedora 39, we will revert back to perl 5.36 and we drop the temporary
build-root with already rebuilt packages.
* Contingency deadline: branching Fedora 39 from Rawhide.
* Blocks release? No.
== Documentation ==
* 5.38.0 perldelta
* An announcement on perl-devel mailing list
* An announcement on fedora-devel mailing list
== Release Notes ==
TBD
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/BiggerESP
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 ==
The Fedora installer includes an EFI System Partition of between 200MB
and 600MB by default, of which the lower size is much too small for
firmware updates on modern hardware and also for future bootloader
features like UKI.
This change will increase the minimum size of the ESP to be 500MB,
which is also the same value used by Microsoft for Windows 10 and
newer.
== Owner ==
* Name: [[User:rhughes| Richard Hughes]]
* Email: richard(a)hughsie.com
== Detailed Description ==
Modern hardware has UEFI firmware updates that are more than 64MB in
size. The OEMs recommend a ESP free space of double the flash size
plus 20MB and fwupd now enforces this requirement to ensure flash
success. As the ESP is often shared between Windows and Linux, and
also used for firmware updates, and soon to be used by UKIs it's not
enough to just allocate a few hundreds of megabytes. Windows 10 and 11
allocates an ESP of at least 500MiB. Arch also specifies a minimum of
512 MiB.
== Feedback ==
There is no alternative -- the ESP has to scale up if we want firmware
updates to continue to work and to support UKIs for next-generation
bootloaders.
== Benefit to Fedora ==
Firmware updates will work on future hardware, and we can boot the
kernel using UKIs using next-generation bootloaders.
== Scope ==
* Proposal owners:
We need to change a number in Anaconda:
https://github.com/rhinstaller/anaconda/pull/4711
== Upgrade/compatibility impact ==
We can't grow the ESP in size, and so this change will only affect new
installs. This is fine, as this will affect new hardware more than old
hardware.
== How To Test ==
Install Fedora and observe that /boot/efi has at least 276MB free
space, even when installed alongside Windows.
== Dependencies ==
Anaconda would need to be modified, and Fedora would have a / or /home
partition that's ~300MB smaller by default than it is now.
== 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)
== Release Notes ==
Fedora now defaults to a larger EFI System Partition which allows
firmware updates to work on newer hardware, and allows future
bootloader and kernel modernizations.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/IncreaseVmMaxMapCount
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 change aims at increasing the default value of the
`vm.max_map_count` sysctl
== Owner ==
* Name: [[User:aleasto| Alessandro Astone]]
* Email: ales.astone(a)gmail.com
== Detailed Description ==
Increase the vm.max_map_count sysctl default value.
The goal is to improve compatibility with Windows games through wine
or steam. Read on "Benefit to Fedora" for examples.
Steam Deck is shipping with a default of `2147483642` (MAX_INT - 5) up
from `65530` of Fedora; it makes sense to follow their lead and set
the same value.
== Feedback ==
<!-- Summarize the feedback from the community and address why you
chose not to accept proposed alternatives. This section is optional
for all change proposals but is strongly suggested. Incorporating
feedback here as it is raised gives FESCo a clearer view of your
proposal and leaves a good record for the future. If you get no
feedback, that is useful to note in this section as well. For
innovative or possibly controversial ideas, consider collecting
feedback before you file the change proposal. -->
This was briefly discussed in #fedora-devel and received positively.
Concerns over possible downsides were raised. I am not aware of any,
but more input here is desired.
== Benefit to Fedora ==
The following Windows games will work out of the box (through wine or steam):
* DayZ: https://steamcommunity.com/app/221100/discussions/0/3199241400256965913/
* Hogwarts Legacy: https://github.com/ValveSoftware/Proton/issues/6510
* Counter Strike 2 (Beta Windows build):
https://www.youtube.com/watch?v=i02n_Ak98TA
* Any other software that might be invoking a lot of mmaps
== Scope ==
* Proposal owners: Add the new default to `/usr/lib/sysctl.d/`
* Other developers: No work will be necessary unless the new default
is found breaking some software
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
Upgrading to the new Fedora release will seamlessly update the
default. No manual intervention is necessary.
== How To Test ==
Temporarily set the new value with `sudo sysctl -w vm.max_map_count=2147483642`
Run any of the software listed above to verify that it now works.
Or run any other software to verify the change causes no regression.
== User Experience ==
More Windows games will work out-of-the-box (through wine or steam)
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Revert the shipped configuration
* Contingency deadline: Final Freeze
* Blocks release? No
== Documentation ==
The default value is currently hard-coded in the kernel, at
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/inclu…
.
It cannot be changed through the kernel defconfig, instead it must be
set through sysctl.
== Release Notes ==
The default value of the vm.max_map_count sysctl is increased
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hi folks!
The "FMN replacement" team has finished writing the new version of our
notification system, and we are ready to deploy!
We plan on:
- deploying the new version on https://notifications.fedoraproject.org
this week,
- keep the old one around but move it to https://apps.fp.o/notifications-old
- redirect from https://apps.fp.o/notifications to the new place.
(fp.o being an abbreviation for fedoraproject.org)
You will thus still be able to access the current FMN, and it will
keep running until F39. Due to the difference in features, we can't
import existing rules into the new system, so we encourage you to
create new rules that suit you as soon as the new system is up and
running.
The change of URLs will happen with the planned outage set for
2023-04-24 08:30 UTC (this Wednesday), see ticket 11266
<https://pagure.io/fedora-infrastructure/issue/11266> for details.
If you have issues with the new FMN, please open infra tickets at:
https://pagure.io/fedora-infrastructure/new_issue
We hope you will enjoy the simpler UI and faster processing speed that
the new FMN brings.
Cheers!
Aurélien
There will be an outage of chat.fedoraproject.org starting at 2023-04-25 07:30 UTC,
which will last approximately 4 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2023-04-25 07:30UTC'
Reason for outage:
Element Matrix services are performing maintenance on chat.fedoraproject.org.
During the maintenance window the service will be affected as follows:
Media uploads and downloads will stop working at the beginning of the maintenance period.
Within the maintenance period the service will be unavailable for an estimated maximum of
15 minutes. We will aim to reduce this downtime as much as possible.
After the service downtime media downloads and uploads will again be functional.
Affected Services:
chat.fedoraproject.org - the fedora.im matrix homeserver.
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/11258
Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.
https://fedoraproject.org/wiki/Changes/Fedora_Images_On_Azure
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 ==
Azure is a massive public cloud and offering an official Fedora Cloud
image there would expand Fedora's user base. It also gives Fedora
Cloud users more options when selecting public clouds.
== Owner ==
* Name: [[User:mhayden| Major Hayden]], [[User:davdunc| David Duncan]]
* Email: major(a)redhat.com, davdunc(a)amazon.com
== Detailed Description ==
We want to:
* Get Azure images built via the existing Pungi processes
* Publish Azure images via Azure's image gallery
* Test these images during regularly scheduled Fedora Cloud test days
before final release
* Ensure that the Azure URN is linked on the Fedora website in the
cloud downloads section (similar to how AWS images are listed today)
== Feedback ==
Another alternative would be to offer a VHD download option from a
mirror, but that
would require users to download the image and upload it to Azure on
their own. This
could be challenging for users without technical skills to complete
these steps or for
users with slow network connectivity.
== Benefit to Fedora ==
* Expands Fedora's official image public cloud footprint to Azure
(currently just AWS and GCP)
* Allows Azure customers to launch official Fedora images which were
tested before launch
* Raises awareness around Fedora Cloud images
== Scope ==
* Proposal owners: Isolated change that does not affect the OS itself
but does improve its availability in public clouds.
* Other developers: Does not affect other developers or features in Fedora.
* Release engineering: [https://pagure.io/releng/issue/11398 #11398]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
This is a net new offering in a cloud where Fedora was not previously offered.
== How To Test ==
* Verify that the Fedora image appears in Azure's image gallery
* Launch an Azure VM with the new Fedora image
* Complete the usual verification that is done on other clouds during
[https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230418.n.1_…
test days]
== User Experience ==
Customers on Azure will notice that a new Fedora official images is
available to them.
Users of other platforms, such as workstation and server, will not see a change.
Customers of other clouds, such as AWS, will not see a change either.
== Dependencies ==
All dependencies are already packaged and tested. One of the biggest
is the Azure Linux
agent ({{package|WALinuxAgent}}), but it has been packaged in Fedora
for multiple releases and is
verified to work on Azure.
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Fedora Cloud Edition is now available for use in Microsoft Azure.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis