F41 Change Proposal: Node.js 22.x by default (system-wide)
by Aoife Moloney
Wiki - https://fedoraproject.org/wiki/Changes/Nodejs22
Discussion thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-node-js-22-x-b...
This is a proposed Change for Fedora Linux.
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 latest release of Node.js to carry a 30-month lifecycle is the
22.x series. As with 20.x, 18.x 16.x, 14.x, 12.x, 10.x and 8.x before
it, Fedora 41 will carry 22.x as the default Node.js interpreter for
the system. The 20.x, and 18.x interpreters will remain available as
parallel-installable options.
== Owner ==
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgallagh(a)fedoraproject.org
* Responsible SIG: Node.js SIG
== Detailed Description ==
Fedora 41 will ship with the latest LTS version of Node.js. '''dnf
install nodejs''' will give users Node.js 22.x and the matching npm
package.
== Benefit to Fedora ==
Node.js is a popular server-side JavaScript engine. Keeping Fedora on
the latest release allows us to continue tracking the state-of-the-art
in that space. For those whose applications do not yet work with the
22.x release, Fedora 41 will also have the 20.x and 18.x releases
available as selectable module streams.
== Scope ==
* Proposal owners:
We will build Node.js 22.x in Rawhide over the next few days as a
non-default version (similar to 18.x in Fedora 40). Once this is done,
we will announce that the switch will occur on or soon after May 27th,
2024. At that time, we will rebuild Node.js 20.x in non-default mode
and rebuild Node.js 22.x as the default "nodejs" package with the
appropriate upgrade path.
* Other developers:
Any developer with a package that depends on Node.js at run-time or
build-time should test with the 22.x alternative package as soon as
possible. Issues should be reported to nodejs(a)lists.fedoraproject.org.
* Release engineering:
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Users running Fedora 39 or Fedora 40 with the nodejs-20 packages will
be automatically upgraded to the 22.x packages when they upgrade to
Fedora 41, which may cause compatibility issues. If users are running
software known not to support Node.js 22.x yet, they will need to
install the nodejs18 compatibility packages and possibly modify their
startup scripts to call `/usr/bin/node-18` rather than
`/usr/bin/node`.
== How To Test ==
* Confirm that `dnf install nodejs` results in Node.js 22.x being installed.
* Confirm that upgrading from Fedora 39 or Fedora 40 with nodejs-20.x
installed results in an upgrade to nodejs-22.x
* Confirm that upgrading from Fedora 39 or Fedora 40 with the nodejs22
package installed results in an upgrade to the nodejs-22.x package,
obsoleting the nodejs22 package.
== User Experience ==
Users will have the 22.x release of Node.js available by default. See
the "Upgrade/compatibility impact" section for specific details.
== Dependencies ==
All packages prefixed with `nodejs-` depend on this package. If they
do not work with Node.js 22.x, they will need to be updated, or made
explicitly dependent upon the `nodejs20` compatibility package or else
removed from Fedora 41.
Prior to the switchover date to Node.js 22.x as the default, packagers
are strongly encouraged to test their existing Node modules with 22.x
by installing the nodejs22 forward-compatibility package (which
provides `/usr/bin/node-22`
== Contingency Plan ==
* Contingency mechanism: Revert to Node.js 20.x as the default Node.js
interpreter. This will require bumping epoch.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
* https://nodejs.org/dist/latest-v22.x/docs/api/
* https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V22.md
* https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/
== Release Notes ==
Fedora 41 now ships with Node.js 22.x as the default Node.js
JavaScript server-side engine. If your applications are not yet ready
for this newer version, they will need to be modified to depend on the
compatibility package nodejs20 and to rely on `/usr/bin/node20` rather
than `/usr/bin/node` for operation.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
1 month
F41 Change Proposal: Perl 5.40 (system-wide)
by Aoife Moloney
Wiki - https://fedoraproject.org/wiki/Changes/perl5.40
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-perl-5-38-syst...
This is a proposed Change for Fedora Linux.
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.40'' version brings a lot of changes done over a year
of development. Perl 5.40 should be released on May 20th 2024. See
[https://metacpan.org/release/PEVANS/perl-5.39.9/view/pod/perldelta.pod
perldelta for 5.39.9] 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>
=== Completed Items ===
=== Items in Progress ===
=== Items to Be Done ===
* Get dedicated build-root from rel-engs ''f41-perl''
* Upstream to release Perl 5.40
* Define perl_bootstrap in perl-srpm-macros
* Rebase perl to 5.40.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 (51 packages)
* Rebuild all updated packages
* [https://jplesnik.fedorapeople.org/5.40/ Final lists of results]
* Merge dedicated build-root to rawhide and remove the dedicated one by rel-engs
* Synchronize packages upgraded in ''f41'' build root
* Rebuild Perl packages: 0 of 606 done (0.00 %)
* Failed packages (0):
== Detailed Description ==
New perl is released every year and updates containing mainly bug
fixes follow during the year. The 5.40.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 ''f41-perl''
build-root against perl 5.40.0 and then if no major problem emerges
the packages will be merged back to ''f41'' build-root.
* Proposal owners: New perl and all packages requiring ''libperl.so''
or versioned ''perl(MODULE_COMPAT)'' will be rebuilt into ''f41-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 ''f41-perl'' build-root
inheriting from ''f41'' build-root. After successful finishing the
rebuild, they will be asked to merge ''f41-perl'' packages back to
''f41'' build-root.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
Vast majority of functionality will be preserved. Only the packages
that failed to build against perl 5.40 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 40 to 41. 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. 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.40 is not suitable for
Fedora 41, we will revert back to perl 5.38 and we drop the temporary
build-root with already rebuilt packages.
* Contingency deadline: branching Fedora 41 from Rawhide.
* Blocks release? No.
== Documentation ==
* 5.40.0 perldelta
* An announcement on perl-devel mailing list
* An announcement on fedora-devel mailing list
== Release Notes ==
TBD, when release candidate appears.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
1 month
F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)
by Aoife Moloney
Wiki - https://fedoraproject.org/wiki/Changes/Drop_Mandatory_Requires_on_JRE
Announced - https://discussion.fedoraproject.org/t/f41-change-proposal-drop-mandatory...
This is a proposed Change for Fedora Linux.
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 ==
Drop the requirement of Java libraries to have Requires on JREs.
== Owner ==
* Name: [[User:mkoncek| Marián Konček]]
* Email: mkoncek(a)redhat.com
== Detailed Description ==
Current [https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_buildreq...
guidelines] require all Java packages to `Require: java-headless or
java-headless >= 1:minimal_required_version`.
Our aim is to drop this explicit requirement on Java library packages.
The requirement should stay for Java applications.
=== Context ===
Java packages are compiled using `javac` into `.class` files and
composed into `.jar` archives. Jar archives can be used as compile or
runtime dependencies for other packages or can be directly executed
with the java command provided by a JRE.
Jar archives can be executed using the command: `java -jar ${FILE}`.
This command executes the `main` method either specified via CLI or
specified within the Jar manifest file.
Java packages, which serve as libraries only, lack the `main` method
and are not executable. Therefore, there is no requirement on any
specific JRE imposed by the library implicitly.
=== Different JDKs ===
This proposal is also related to the topic of different JDKs.
Developers may want to use or build packages which use a JDK different
than the one provided by the `java-<N>-openjdk` package. After this
proposal was implemented, they would be able to depend on Java library
packages with no introduction of the OpenJDK package.
=== Rationale ===
Java libraries are more similar to native libraries than to libraries
written in dynamic scripting languages. They are compiled to a
bytecode and are not executable. Java libraries can be used as
dependencies for any Java application and there is no implicit
dependency on the system default JDK.
Java applications, on the other hand, are expected to be tested and to
work with the system JDK and from the user's perspective: after
installing an application they must be able to simply run the binary.
Therefore the `Requires` on the system JDK is kept for Java
applications.
== Feedback ==
== Benefit to Fedora ==
* Very little user-visible benefit.
* Reduced dependencies of Java packages.
* Simplified maintenance of Java packages.
** Smaller impact of JDK major updates (e.g. `1.8.0 -> 11 -> 17 ->
21`). Introducing a new system version of JDK requires the rebuild of
each Java package in order to have updated `Requires` to contain the
newest version.
== Scope ==
* Proposal owners:
** Find all Java applications in Fedora, i.e. packages which
`BuildRequire` `java-devel / maven-local / ant` and at the same time
install files into `/bin` or `/sbin` or `/usr/bin` or `/usr/sbin`.
** Open pull requests adding `Requires: java-headless` into their `.spec` file.
** Remove `Requires` generator from
[https://src.fedoraproject.org/rpms/javapackages-tools/blob/8714cc1d03d3f3...
javapackages-tools]
** Wait for a mass rebuild.
* Other developers:
** Maintainers of Java applications will need to add an explicit
`Requires: java-headless` field into their `.spec` file or a specific
version of thereof (such as `java-17-openjdk-headless`).
* Release engineering: [https://pagure.io/releng/issue/12069 #12069]
** Mass rebuild is not required, this change can propagate via natural rebuilds.
* Policies and guidelines:
** Guidelines need to be modified
([https://pagure.io/packaging-committee/pull-request/1360 open Pull
Request]).
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
* For Java libraries:
** This change is removing `Requires` and therefore users manually
installing a Java library will not additionally install the JVM.
* For Java applications:
** After fully implemented, applications will no longer be installable
along with any JVM but rather only the system one (unless the package
maintainer decides otherwise)
== How To Test ==
* Installing a Java library should not typically install JVM (but can
if the library depends on a Java application)
* Installing a Java application MUST cause the installation of the
system-wide JVM (or a different version thereof)
* Executing a binary installed in typical locations (such as
`/usr/bin`) MUST NOT cause an error related to the JVM not being
installed.
== User Experience ==
Users with no Java application installed, but some Java libraries
installed: the JVM may be automatically uninstalled as it is possibly
not required by anything.
It is possible that there are users with only some older JVM
installed. The following depends on the decision of each Java
application package maintainer, but the general expectation is that
the system-wide JVM will be installed and the older JVM will no longer
be required by other packages.
Users who explicitly installed JVMs of various versions: no change.
== Dependencies ==
* `javapackages-tools`
** This change allows the removal of the `Requires` generator.
== Contingency Plan ==
* Contingency mechanism:
** In case of unexpected problems, the `Requires` generators can be
reintroduced into `javapackages-tools` and packages can be rebuilt.
* Contingency deadline: Branch Fedora Linux 41 from Rawhide Tue 2024-08-06
* Blocks release? No
== Documentation ==
No documentation outside of this document.
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
1 month, 1 week
F41 Change Proposal: Fedora Miracle Spin (self-contained)
by Aoife Moloney
Wiki - https://fedoraproject.org/wiki/Changes/FedoraMiracle
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-fedora-miracle...
This is a proposed Change for Fedora Linux.
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 an official Fedora Spin shipping the up-and-coming Miracle Window Manager
== Owner ==
* Name: [[User:mattkae| Matthew Kosarek]], [[User:tsimonq2| Simon
Quigley]], [[User:ngompa| Neal Gompa]]
* Email: matthew(a)matthewkosarek.xyz, simon(a)tsimonq2.net, ngompa13(a)gmail.com
== Detailed Description ==
The Miracle Window Manager is a tiling window manager based on the Mir
compositor library. While it is a newer project, it contains many
useful features such as a manual tiling algorithm, floating window
manager support, support for many Wayland protocols, proprietary
Nvidia driver support, and much more. Users are increasingly
interested in using miracle in various systems.
The goal of the miracle spin is to build a complete and elegant tiling
window experience within the Fedora ecosystem.
== Feedback ==
== Benefit to Fedora ==
Miracle will provide Fedora with a high-quality Wayland experience
built with support for all kinds of platforms, including low-end ARM
and x86 devices. On top of this, Fedora will be the first distribution
to provide a Miracle based spin, ensuring that it will become the de
facto distribution for running Miracle.
== Scope ==
* Proposal owners:
** SIG request: [https://pagure.io/fedora-infrastructure/issue/11856 #11856]
** comps: TODO
** fedora-release-miracle: TODO
** kickstart: TODO
** livesys-scripts: TODO
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/12077 #12077]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: [https://pagure.io/Fedora-Council/tickets/issue/491 #491]
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
This is a new spin, so there is nothing.
== How To Test ==
{{package|miracle-wm}} is available in Fedora Linux 40, so it can be
installed on top of something like the existing Sway spin and
configured to reuse much of the tools used there.
For Fedora Linux 41, once the spin is produced, people can download
and try the experience intended to be released.
== User Experience ==
The experience will be similar to the Sway spin, though with more
features there may be some different choices on defaults.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Push off to the next Fedora release.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
This release introduces the Fedora Miracle Spin. The Fedora Miracle
Spin aims to provide the premiere Miracle window manager experience on
top of Fedora Linux, the leading edge platform for developers and
users alike.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
1 month, 1 week
Fedora 40 Elections are now open!
by Aoife Moloney
Hello everyone,
I hope you all are enjoying Fedora 40, and this release also marks the
start of a new election cycle[1]. As of now, the nomination period for
positions on Fedora Council, Fedora Mindshare, FESCo and EPEL Steering
Committee is now open! 🎉
We have some slight changes to some elections this cycle, with more detail
available to read on the Elections blog post coming tomorrow as part of the
Fedora Council hackfest mini-series, but for now the main things you need
to know are the following:
- We are welcoming the EPEL Steering Committee to our elections cycle!
There are currently four seats available for the EPEL Steering Committee,
so if you or someone you know would like to serve for a term of 12 months
on this committee, you can nominate yourself or someone else on their
candidate nominations page[2].
- The Fedora Council is moving to a once-per-year election, and we will
be electing two new members for this cycle for a 12-month term. If you
would like to serve on the council, or know someone who would be a great
fit, you can nominate yourself or other(s) on the council nominations
page[3].
- The Fedora Engineering Steering Committee (FESCo) will have four seats
open this cycle, and will remain on the current twice per year elections
cadence. If you would like to nominate yourself, or someone you know who
would be a great addition to FESCo, you can nominate yourself or others on
their nominations page[4].
- The Fedora Mindshare Committee has one seat open for this election
term, and their election schedule will also stay on the twice-per-year
cadence. If you would like to get involved, or know someone who would be a
great person to be considered for the Mindshare committee activities like
budget management with the FCA, ambassador work, outreachy work, etc, you
can nominate yourself and/or them now on the nominations page[5].
*Very Important:* Please do not nominate someone for a seat on any of the
above governance bodies without their explicit consent.
The nominations period will be open until Wednesday, May 8th and events
during the F40 elections period can be found on the schedule[6].
[1]
https://docs.fedoraproject.org/en-US/program_management/pgm_guide/elections/
[2] https://fedoraproject.org/wiki/EPEL/Nominations
[3] https://fedoraproject.org/wiki/Council/Nominations
[4] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
[5] https://fedoraproject.org/wiki/Mindshare/Nominations
[6] https://fedorapeople.org/groups/schedule/f-40/f-40-elections-tasks.html
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
1 month, 1 week
Announcing Fedora Linux 40
by Matthew Miller
Fedora Linux 40 is now officially available.
Read the details in our Fedora Magazine article at:
* https://fedoramagazine.org/announcing-fedora-linux-40
or download installer images from:
* https://fedoraproject.org/
or, of course, simply upgrade your already-installed systems, which
shouldn't take much longer than ordering and consuming your favorite
hot and possibly caffeinated beverage. If you run into any trouble, or
just have questions, you can find help at
* https://ask.fedoraproject.org/
There are several important release-day bugfix and security updates
available today as well. If you upgrade from an earlier Fedora Linux
release, you'll get them as part of that. For new systems, please
make sure to check for and apply updates as soon as possible.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1 month, 1 week
Intent to start ARC investigation git-forge replacement
by Tomas Hrcka
Hello, Fedora community,
Following on from the Fedora Council's decision to investigate Forgejo
and GitLab as potential replacements[1], the Community Platform
Engineering team will start an ARC[2] investigation to compare
proposed alternatives for current pagure use cases.
The council has defined some broad requirements for the team to
consider during this investigation. But we would like inputs from all
gitforge user groups in our community.
So, if you have a specific use case or workflow, share it with us in
the form of a user story in this ticket[6], or consider joining the
ARC team for this investigation.
High-level overview of investigation requirements by the council:
1. Suitability for dist-git and src.fedoraproject.org replacement
2. Suitability for replacement of Bugzilla for packaging issues and
review process
3. Suitability for replacement of Pagure and Bugzilla for release
issues (change process, blocker bugs, etc)
* https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
* https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
4. Suitability for replacement of Pagure for SIG and Team ticket
tracking (e.g. FESCo tracker)
5. Cost of hosting and maintenance (hardware + time and resources
from CPE and wider infrastructure team)
6. Ease of migration from current Pagure, GitHub, and GitLab
7. Ease of extension and enhancement — can we improve things
ourselves to add missing features/features that are cool and useful
like CI integration?
8. New features like Asciidoc support, Online editor, and others to
make things easier for the Fedora teams and their workflows.
9. Estimate Future risk for Fedora project and Infrastructure team
1. Long-term project vision
2. Platform SMEs in the Fedora Infrastructure team and the wider community
These requirements do not represent feature sets, but rather a
high-level overview of our current use cases.
CPE has already done some initial mapping of how our current
applications interact with distgit[3] and if we have missed anything,
please let folks know in a thread on discussions.fp.o[4].
The aim of this investigation will not be to pick one solution or the other,
but instead, focus on providing the Fedora Council and decision
makers[5] with an extensive comparison of the two.
For discussion about the purpose of this investigation please use the
discussions.fp.o thread[7]
The ARC investigation will commence in early May.
[1] - https://communityblog.fedoraproject.org/2024-git-forge-evaluation/
[2] - https://fedora-arc.readthedocs.io/en/latest/index.html
[3] - https://fedora-arc.readthedocs.io/en/latest/dist-git-move/index.html#inte...
[4] - https://discussion.fedoraproject.org/t/dist-git-decoupling-investigation/...
[5] - https://pagure.io/Fedora-Council/tickets/issue/488
[6] - https://pagure.io/fedora-infra/arc/issue/164
[7] - https://discussion.fedoraproject.org/t/arc-git-forge-investigation/114018
Tomas Hrcka
Cat herder at Community Platform Engineering team
fas: humaton
libera.CHAT: jednorozec
matrix: @humaton:fedora.im
1 month, 1 week
F41 Change Proposal: Replace Redit with Valkey (system-wide)
by Aoife Moloney
Wiki - https://fedoraproject.org/wiki/Changes/Replace_Redis_With_Valkey
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-replace-redit-...
This is a proposed Change for Fedora Linux.
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.
= Replace Redis with Valkey =
{{Change_Proposal_Banner}}
== Summary ==
Obsolete Redis for Valkey due to Redis's license change to RASLv2/SSPL.
== Owner ==
* Name: [[User:jonathanspw|Jonathan Wright]]
* Email: jonathan(a)almalinux.org
== Detailed Description ==
We will replace Redis with Valkey due to the recent licensing changes
in Redis, which have rendered it incompatible with Free and Open
Source Software (FOSS) principles. This shift in Redis's licensing can
impact Fedora's commitment to FOSS, potentially limiting users'
freedom to modify and redistribute the software under the same terms.
Valkey, a fork of Redis, emerges as a viable alternative because it
retains a FOSS-compatible license and has robust community and
developmental support. Adopting Valkey allows us to continue offering
users a powerful in-memory data structure store without compromising
on licensing restrictions.
== Feedback ==
== Benefit to Fedora ==
Redis previously used the BSD license. Redis's shift to the Server
Side Public License (SSPL) that Fedora does not allow poses an issue.
Valkey adheres to the original BSD licensing model, thus maintaining
full FOSS compatibility. This commitment is bolstered by substantial
backing from the Linux Foundation and the migration of many former
Redis contributors to Valkey, ensuring a robust development
environment and continuity of expertise.
As the package owner of Valkey in Fedora, my interactions with the
Valkey upstream project have underscored their strong dedication to
working with distributions. The Valkey team is responsive and
proactive in discussions, which facilitates effective package
management and integration within Fedora. Their commitment to open
collaboration significantly benefits Fedora, ensuring that Valkey is
not only technically sound, but also aligns with Fedora's principles
and community values.
This shift to Valkey allows Fedora to maintain its leadership in
offering powerful FOSS-aligned technologies while supporting a project
that values open source integrity and collaboration. This is crucial
for keeping Fedora at the forefront of providing robust,
community-supported software solutions to its users.
== Scope ==
* Proposal owners: add a valkey-compat package which will port Redis
configurations to Valkey. Valkey 7.2.5 is 100% compatible with Redis.
Add "Obsolete: redis" to valkey-compat package. valkey-compat will
require valkey. This will allow us to eventually retire the
valkey-compat sub-package at some point in the future.
* Other developers: N/A
* Release engineering: N/A
* 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 ==
When upgrading to Fedora Linux 41, systems with `redis` installed will
be switched to `valkey` via the `valkey-compat` package. The change
should be mostly transparent to users as the `valkey-compat` package
provides config and data migration for most common configurations.
The valkey systemd units will have aliases for redis to ease the
migration for users.
== How To Test ==
A COPR is available at
https://copr.fedorainfracloud.org/coprs/jonathanspw/valkey/ with the
"Obsoletes" in place so the migration script can be tested.
== User Experience ==
This is intended to be as invisible to users as possible. If the
change proposal is approved the valkey serviced units will be aliased
to redis.service to ease the transition.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Do not
obsolete Redis with Valkey
* Contingency deadline: N/A
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
1 month, 2 weeks
