This is your reminder that several Change proposal deadlines for
Fedora 33 are approaching.
* 2020-06-24: Proposal deadline for Changes requiring infrastructure changes
* 2020-06-30: Proposal deadline for Changes requiring mass rebuild
* 2020-06-30: Proposal deadline for System-Wide Changes
* 2020-07-21: Proposal deadline for Self-Contained Changes
For the full schedule, see
https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/.NETOnAarch64
== Summary ==
.NET Core will now be available on Fedora on aarch64, in addition to x86_64.
== Owner ==
* Name: [[User:omajid| Omair Majid]], [[SIGs/DotNet|DotNet SIG]]
* Email: omajid(a)redhat.com, dotnet-sig(a)lists.fedoraproject.org
== Detailed Description ==
Fedora currently includes .NET Core only on x86_64. We want to make
.NET Core available on Aarch64 as well for our users.
.NET Core documentation calls the Linux/aarch64 platform "linux-arm64".
This platform has been supported by upstream .NET Core for a little
while now (2 years or so). But upstream cross-compile it on x86_64.
With recent upstream improvements, we can now build .NET Core for
aarch64 on aarch64.
In the spirit of being First on Fedora, we want to make .NET Core
available for aarch64 on Fedora.
== Feedback ==
We don't have any feedback at this time from the community.
Upstream is enthusiastic and supportive of us enabling this in Fedora.
== Benefit to Fedora ==
This change improves the coverage of Fedora packages on aarch64. .NET
Core was previously only available on x86_64; it's now available on
aarch64 as well. Users who are using Fedora on aarch64 can now use the
normal distribution packages for .NET Core, instead of having to find,
download an installing .NET Core some other way. As a result of this,
Fedora becomes a more attractive target for developing and deploying
applications on aarch64.
== Scope ==
* Proposal owners:
# Will update .NET Core to bootstrap and build on aarch64 (along with
x86_64). This shouldn't affect any other packages.
# Will work with package owners of packages that .NET Core depends on
if those specific dependencies of .NET Core are broken, buggy or
un-available on aarch64
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (checked with #fedora-releng)
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
There is no known impact on upgrades.
.NET Core was just not available Fedora for aarch64 in previous
releases of Fedora. It will be available in Fedora starting Fedora 33.
.NET Core is not a dependency of any other package, so users running
Fedora on aarch64 and then upgrading from Fedora 32 to 33 will not
automatically pull it in. They will have to install it manually.
== How To Test ==
# Install Fedora 33 on aarch64
# Install .NET Core: <code>sudo dnf install dotnet-sdk-3.1</code>
# Run .NET Core: <code>dotnet --info</code>
The above steps should install .NET Core and show the .NET Core SDK
and Runtime version numbers. There should be no error messages or any
other failures.
== User Experience ==
- Users using Fedora on aarch64 as a platform for .NET Core
development will be able to use the Fedora-provided packages for .NET
Core
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Proposal owner will revert packaging changes
and switch back to how .NET Core was built in Fedora 32.
* Blocks release? No
* Blocks product? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
.NET Core is now available on aarch64! You can install .NET Core on
Fedora on aarch64 using the normal packaging tools: <code>sudo dnf
install dotnet-sdk-3.1</code>
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS
== Summary ==
This proposal adds cgroup based resource protections for the active
graphical session. This is done by passing a memory protection of
250MiB to active users (capped at 10% of system memory) and by
enabling other cgroup controllers (CPU, IO) to ensure important
session processes get the resources they need.
See: https://pagure.io/fedora-workstation/issue/154
== Owner ==
* Name: [[User:benzea|Benjamin Berg]]
* Email: bberg(a)redhat.com
* Product: Workstation
* Responsible WG: Workstation
== Detailed Description ==
Graphical sessions should always be responsive, even when the machine
is doing a lot work or in the extreme case has started to thrash. We
have started to ship EarlyOOM with F32, however, while it is a good
solution to this date, it is shipped with the understanding of being
superseded by other approaches in the future.
With `uresourced` a small daemon was written that enables protection
of the graphical user session. It serves the following main purposes:
* Safely modify existing GNOME systemd units to closer adhere to
https://systemd.io/DESKTOP_ENVIRONMENTS/ (until this is merged
upstream).
* Enables the CPU and IO cgroup controllers for users to prevent e.g.
fork bombs from taking over the system.
* Allocates a memory guarantee for any *active* user which is
distributed to core session processes.
Precautions are in place to not negatively affect systems:
* Active users will receive a protected memory allocation of 250MiB
allocation, but capped at 10% of system memory. So low memory systems
should not be negatively impacted. Said differently, the memory
subsystem treats the core session processes in comparison to
everything else as if they were using 250MiB less than they actually
are.
* `uresourced` detects whether the user session is using systemd to
prevent passing memory guarantees to processes that are not important
(e.g. not a GNOME session).
* Enabling the IO controller has no effect on Fedora currently.
NOTES:
* `uresourced` is designed to be obsoleted. Everything it does should
be absorbed by other upstreams. However, it is a good and safe
solution that eases development and permits shipping the benefits to
users now.
* Enabling the cgroup controllers may slightly increase the scheduling
overhead that the kernel imposes. I don't have numbers right now, but
expect this to be <=1% of overall system CPU time.
== Benefit to Fedora ==
This change proposal will improve interactivity of graphical sessions
in certain situations. It also is an important step on the path to
reap the benefits of systemd and cgroups in workstation scenarios.
== Scope ==
* Proposal owners:
* Install `uresourced` on workstations by default
* Add a preset to enable `uresourced` by default
* Other developers: no further changes are needed
* Release engineering: [https://pagure.io/releng/issue/9592]
* Policies and guidelines: N/A (not needed)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
No impact. The worst case scenario is that the feature will not be enabled.
== How To Test ==
Testing this has multiple aspects. From the technical side, a test is
as simple as:
* Install and enable `uresourced`
* Reboot (to make absolutely sure the user session has picked up all
changes, logout may *not* be sufficient)
* Check values in `/sys/fs/cgroup/user.slice/memory.low`,
`/sys/fs/cgroup/user.slice/user-1000.slice/memory.low`,
`/sys/fs/cgroup/user.slice/user-1000.slice/user(a)1000.service/memory.low`
and `/sys/fs/cgroup/user.slice/user-1000.slice/user(a)1000.service/session.slice/memory.low`
(should usually be 250MiB with the default configuration).
* Verify that the allocation is zero if the user is not active on any
seat (e.g. switch to GDM and log in via SSH or by doing a `sleep 10;
cat ...` and coming back).
* Check enabled controllers in
`/sys/fs/cgroup/user.slice/user-1000.slice/user(a)1000.service/cgroup.controllers`
(should be `cpu io memory pids`).
Beyond that, a test can be done to show that the cgroup kernel
controllers are actually beneficial in various scenarios. Possible
examples are:
* Running mprime
(http://www.mersenne.org/ftp_root/gimps/p95v298b6.linux64.tar.gz);
choose local stress test, repeat by selecting 15 <br>NOTE: mcatanzaro
has reported a huge impact, with both the session remaining mostly
responsive and EarlyOOM not kicking in (this makes sense, as overall
memory pressure is much lower, i.e. the session is waiting on memory
related IO less). The proposal owners have not been able to reproduce
this corner case so far.
* Log in two user A and B (same seat), run `stress-ng -c NCPUS` in
both. Switch between them and look at `top` to verify that the active
user gets a 5 times higher CPU share overall.
== User Experience ==
See other sections.
== Dependencies ==
There are no further dependencies.
== Contingency Plan ==
* Contingency mechanism: Remove uresourced from the default install
set and possibly also remove the preset again
* Contingency deadline: Final freeze
* Blocks release? No
== Documentation ==
Upstream is identical to the change owner. The upstream repository has
a further README https://gitlab.freedesktop.org/benzea/uresourced
(which should not contain any more information than what is here).
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/XorgUtilityDeaggregation
== Summary ==
The collection packages
`xorg-x11-{apps,font-utils,server-utils,utils,xkb-utils}` will be
retired, and the individual utilities within them will be packaged
separately.
== Owner ==
* Name: [[User:ajax|Adam Jackson]]
* Email: ajax(a)redhat.com
== Detailed Description ==
The `xorg-x11-*` collection packages are somewhat arbitrary
collections of the stock utilities and sample applications from the
X.org distribution, mostly for the convenience of comps and other
package-set-definition tooling. Typically not all of the utilities in
a given package will be needed simultaneously, and the version numbers
of the package do not logically reflect the upstream version of any
particular component. Most of the packages that require a particular
component Require that specific component name, as opposed to the
collection package. In addition, some of the components (notably
`luit` and `edid-decode`) are not in fact X.org packages anymore but
have other upstreams.
Deaggregating the individual components will allow for smaller
installed image sizes, less frequent rebuilds for unrelated changes,
and greater flexibility in choice of upstream.
== Feedback ==
It is not strictly necessary to retire the collection packages, they
could instead be converted to metapackages like `xorg-x11-drivers`
that simply Require all the things they used to Provide. However, as
the majority of consumers of these utilities depend on the specific
utility and not the collection, retiring them should require touching
quite few consumers. On the other hand, the upgrade migration path is
more difficult if the collections are retired. I'm open to either
approach.
== Benefit to Fedora ==
1. Smaller installed footprint due to eliminating unused leaf utilities.
2. Utilities will be rebuilt only as they actually change.
3. Utilities that have a new home besides X.org will not be deceptively named.
== Scope ==
* Proposal owners:
Prepare new independent packaging of each utility, and update or
retire the corresponding collection packages. This is a few dozen new
packages, but they are all nearly trivial.
* Other developers: N/A (not a System Wide Change)
* Release engineering:
We may want to update comps to include the new packages, or we may
simply allow them to be brought in by the packages that actually
Require them.
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
If the collection packages are retired, the new packaging will need to
Obsolete the old collection packages.
== How To Test ==
Spins and package sets that currently include the collection packages
should be tested to verify that they still contain everything they
need after this conversion.
== User Experience ==
Marginally smaller installed image, fewer unrelated updates.
== Dependencies ==
Full list of affected consumer packages TBD.
== Contingency Plan ==
Leave the packaging as it is.
== Documentation ==
None.
== Release Notes ==
Release notes should reflect the fact that the collection packages
have been retired or made meta, and the list of affected utilities
should be noted.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/golang1.15
== Summary ==
Rebase of Golang package to upcoming version 1.15 in Fedora 33,
including rebuild of all dependent packages(pre-release version of Go
will be used for rebuild, if released version will not be available at
the time of the mass rebuild).
== Owner ==
* Name: [[User:Jcajka| Jakub Čajka]], [[User:alexsaezm| Alejandro Sáez
Morollón]]
* Email: jcajka(a)redhat.com, alexsaezm(a)redhat.com
== Detailed Description ==
Rebase of Golang package to upcoming version 1.15 in Fedora 33. Golang
1.15 is schedule to be released in August 2020.
Due to current nature and state of Go packages, rebuild of dependent
package will be required to pick up the changes.
== Benefit to Fedora ==
Staying closely behind upstream by providing latest release of golang,
which includes performance improvements and improvements in support
for currently supported platforms among other bug fixes and new
features. For complete list of changes see upstream change notes at
https://tip.golang.org/doc/go1.15 . In result Fedora will be providing
solid development platform for Go language.
== Scope ==
* Proposal owners: Rebase golang package in Fedora 33, help with
resolving possible issues found during package rebuilds.
* Other developers: Fix possible issues, with help from golang maintainers.
* Release engineering: Rebuild of dependent packages as part of
planned mass-rebuild. Tracking ticket
https://pagure.io/releng/issue/9548
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
None
== How To Test ==
;0.
:a)Install golang 1.15 from rawhide and use it to build your
application(s)/package(s).
:b)Scratch build against rawhide.
;1.
:Your application/package built using golang 1.15 should work as expected.
== User Experience ==
None
== Dependencies ==
<pre>
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(golang)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
</pre>
<pre>
Omitted due to the number of packages listed ~1300.
</pre>
Not all of listed require re-build as they might not ship binaries
and/or do not use golang compiler during build, but only use Go rpm
macros that pull it in to every build root.
== Contingency Plan ==
* Contingency mechanism:Reverting to golang version 1.14.X if
significatnt issues are discovered.
* Contingency deadline: Beta Freeze(?)
* Blocks release? No
* Blocks product? No
== Documentation ==
https://tip.golang.org/doc/go1.15
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/ModularPolicy
== Summary ==
Establish a set of rules for Modular content in Fedora to ensure an
optimal user and packager experience.
== Owner ==
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgallagh(a)redhat.com
== Detailed Description ==
Over the last several months, members of the Modularity WG and FESCo
have been working to establish a policy for module inclusion in
Fedora. We now have a proposal that FESCo requested be taken to the
Fedora community via the Change Proposal.
There is a preview of the new policy available at
https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/
== Benefit to Fedora ==
This policy makes explicit what packagers can and cannot do with
Modules in Fedora, which should avoid future issues like those that
were seen during the Fedora 31 and Fedora 32 cycles.
== Scope ==
* Proposal owners:
The proposal is written, so minimal work remains. We may need to make
revisions or clarifications based on public feedback.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
N/A this is not a user-facing change.
== Dependencies ==
N/A (not a System Wide Change)
== 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)
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/PostgreSQL_13
== Summary ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from version 12 to version 13 in the non-modular (main) builds.
== Owner ==
* Name: [[User:panovotn| Patrik Novotny]]
* Email: panovotn(a)redhat.com
== Detailed Description ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from version 12 to version 13 in the non-modular (main) builds.
This also involves updating and rebuilding the PostgreSQL plugins that
depend on postgresql server.
== Benefit to Fedora ==
Latest stable software is used by Fedora users.
== Scope ==
* Proposal owners:
<!-- What work do the feature owners have to accomplish to complete
the feature in time for release? Is it a large change affecting many
parts of the distribution or is it a very isolated change? What are
those changes?-->
**Prepare PostgreSQL 13 as a module for Rawhide and at least one
stable Fedora release (done)
**Prepare PostgreSQL 12 as a module for Rawhide, so there would be a
failover in case of problems
**Build PostgreSQL 13 to Rawhide
**Check software that requires or depends on `postgresql-server` or
`libpq` packages for incompatibilities
**Gather user input on the changes between PostgreSQL 12 and PostgreSQL 13
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The PostgreSQL client library (libpq component) is compatible, so
there shouldn't be any issues, but rebuild of the depended components
is better to be sure. There is a
[https://copr.fedorainfracloud.org/coprs/panovotn/postgresql-13beta2/
COPR build] available for testing.
Server plugins might require a newer version update, because they
sometimes have explicit server requirements. PostgreSQL maintainer
will help fixing/rebuilding any issues in the plugins.
== How To Test ==
Usual testing as when upgrading between major PostgreSQL versions,
running `postgresql-setup --upgrade` is necessary between major
versions.
Test that all other software runs well with PostgreSQL 13.
== User Experience ==
The users will have to upgrade their databases the same way as between
major PostgreSQL versions, aka `postgresql-setup --upgrade`.
If users want to stick with PostgreSQL 12 for a little longer, there
should be PostgreSQL 12 module.
If users want to test it before it reaches Fedora 33, there is a
[https://copr.fedorainfracloud.org/coprs/panovotn/postgresql-13beta2/
COPR build] available.
== Dependencies ==
There are some packages (mostly server plugins), that build on top of
PostgreSQL. Since the separation of PostgreSQL client library (libpq
component), only packages that build server plugins should use
postgresql package in BuildRequires, others should use libpq. In both
the cases, rebuild should be done to make sure all potential binary
incompatibilities are handled.
== Contingency Plan ==
Modules will provide the functional version of PostgreSQL 12,
available to all users.
== Documentation ==
Upgrade startegy: https://www.postgresql.org/docs/13/upgrading.html
== Release Notes ==
Release notes for PostgreSQL 13 release:
https://www.postgresql.org/docs/13/index.html
Overall overview of the changes and improvements:
https://www.postgresql.org/docs/13/release-13.html
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis