If you have a Change proposal that requires changes to Infrastructure,
those proposals must be submitted (i.e. in ChangeReadyForWrangler
category) by 26 June.
Other deadlines approaching:
* 2019-07-02 — Changes requiring mass rebuild
* 2019-07-02 — System-Wide changes
* 2019-07-23 — Self-contained changes
For more development milestones in the F31 schedule, see:
https://fedorapeople.org/groups/schedule/f-31/f-31-devel-tasks.html
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
== Summary ==
Stop building i686 kernels, reduce the i686 package to a
kernel-headers package that can be used to build 32bit versions of
everything else.
== Owner ==
* Name: [[User:jforbes| Justin Forbes]]
* Email: jforbes(a)fedoraproject.org
== Detailed Description ==
The i686 kernel is of limited use as most x86 hardware supports 64bit
these days. It has been in a status of "community supported" for
several Fedora releases now. As such, it gets very little testing,
and issues frequently appear upstream. These tend to go unnoticed for
long periods of time. When issues are found, it is often a long time
before they are fixed because they are considered low priority by most
developers upstream. This can leave other architectures waiting for
important updates, and provides a less than desirable experience for
people choosing to run a 32bit kernel.
With this proposal, the i686 kernel will no longer be built. A kernel
headers package will still exist, and all 32bit packages should
continue to build as normal. The main difference is there would no
longer be bootable 32bit images.
This was last proposed with Fedora 27, but it was deferred as an i686
SIG was to be created to handle issues going forward. That SIG has
been largely unresponsive. The only thread so far this year has been
a thread starting with "Hello, I noticed that the x86 group hasn't had
any reports in a while. As the absentee sponsor of the group, I would
like to remind people on the list and interested in keeping x86_32 in
Fedora releases that there is general work which needs to be done by
people interested. " And the only response was one person saying they
would no longer have access to legacy i686 hardware as of August.
== Benefit to Fedora ==
More testable kernel updates, faster fixes for security bugs, and
lowered exposure.
== Scope ==
* Proposal owners:
Changes to the kernel spec to stop the actual i686 builds, but keep
the kernel-headers package.
* Other developers: NA
* Release engineering: [https://pagure.io/releng/issue/8461]
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
of deliverables]]: Drop i686 based images
* Policies and guidelines: N/A (not needed for this change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
32bit i686 users will need to reinstall as x86_64 with the next release.
== How To Test ==
N/A Nothing to test, we simply stop producing a flavor of the kernel
package. As there is no direct upgrade path from i686 -> x86_64, users
with capable hardware will have to reinstall.
== User Experience ==
The few 32bit users will have the full lifecycle of Fedora 30 to
choose a time to upgrade to a 64bit installation. Some old hardware
will no longer be supported by fedora.
== Dependencies ==
32 bit x86 images can no longer be built.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Start building
an i686 kernel again
* Contingency deadline: As QA requires for image candidates
* Blocks release? Yes
* Blocks product? product Fedora 31
== Documentation ==
The lack of an i686 image will need to be documented.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/GLIBC230
== Summary ==
Switch glibc in Fedora 31 to glibc version 2.30.
== Owner ==
* Name: [[User:fweimer|Florian Weimer]]
* Email: fweimer(a)redhat.com
== Detailed Description ==
The GNU C Library version 2.30 will be released at the beginning of
August 2019; we have started closely tracking the glibc 2.30
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 31 will branch after the
GLIBC 2.30 upstream release. However, the mass rebuild schedule means
Fedora 31 will mass rebuild (if required) after GLIBC 2.30 upstream
freezes ABI for release, but before the actual release, so careful
attention must be paid to any last minute ABI changes.
== Benefit to Fedora ==
Stays up to date with latest security and bug fixes from glibc upstream.
== Scope ==
* Proposal owners: Update glibc to 2.30.
* Other developers: Developers need to ensure that rawhide is stable
and ready for the Fedora 31 branch. Given that glibc is backwards
compatible and we have been testing the new glibc in rawhide it should
make very little impact when updated, except for the occasional
deprecation warnings and removal of legacy interfaces from public
header files.
* Release engineering: [https://pagure.io/releng/issue/8462 #8462]
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: Not needed for this change
== Upgrade/compatibility impact ==
The library is backwards compatible with the version of glibc that was
shipped in Fedora 29.
Some packaging changes required, see:
https://sourceware.org/glibc/wiki/Release/2.30#Packaging_Changes
We fully expect to fix all packaging changes in Fedora Rawhide given
that glibc in Rawhide is tracking what will become glibc 2.30.
== How To Test ==
The GNU C Library has its own testsuite, which is run during the
package build and examined by the glibc developers before being
uploaded. This test suite has 5900+ tests that run to verify the
correct operation of the library. In the future we'll also be running
the microbenchmark to look for performance regressions as well as
behavioural ones.
== User Experience ==
Users will see improved performance, many bugfixes and improvements to
POSIX compliance, additional locales, etc. The glibc 2.30 NEWS update
will include more details.
== Dependencies ==
All packages do not need to be rebuilt.
== Contingency Plan ==
* Contingency mechanism: Given that Rawhide has started tracking glibc
2.30, no show-stopper problems are expected. At this point, we can
still revert to upstream version 2.29 if insurmountable problems
appear, but to do so may require a mass rebuild to remove new symbols
from the ABI/API.
* Contingency deadline: Upstream ABI freeze deadline of 2019-07-01.
* Blocks release? Upgrading glibc does block the release. We should
not ship without a newer glibc, there will be gcc and language
features that depend on glibc being upgraded. Thus without the upgrade
some features will be disabled or fall back to less optimal
implementations.
== Documentation ==
== Release Notes ==
* Release Notes tracking: <will be assigned by the Wrangler>
The GNU C Library version 2.30 will be released at the beginning of
August 2019. The current NEWS notes can be seen here as they are
added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Greetings, all!
The elections for FESCo election for Fedora 30 have concluded, and the results
are shown below.
FESCo is electing 4 seats this time.
A total of 205 ballots were cast, meaning a candidate
could accumulate up to 1230 votes (205 * 6).
The results for the elections are as follows:
# votes | name
- --------+----------------------
695 | Stephen Gallagher
687 | Igor Gnatenko
615 | Aleksandra Fedorova
569 | Petr Šabata
- --------+----------------------
525 | Jeremy Cline
444 | Fabio Valentini
Congratulations to the winning candidates, and thank you all
candidates for running this elections!
Full election results for all three elections are posted to the Fedora
Community Blog[1]
[1] https://communityblog.fedoraproject.org/fedora-30-elections-results/
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Voting is now open for the Fedora 30 election cycle. You can vote in
the Elections app[1]. Interviews with candidates are available on the
Fedora Community Blog[2], with links available in the Elections app.
Voting ends at 23:59 UTC on 20 June.
[1] https://elections.fedoraproject.org
[2] https://communityblog.fedoraproject.org/?p=7774
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/CustomCryptoPolicies
== Summary ==
This new feature of crypto-policies allows system administrators and
third party providers to modify and adjust the existing system-wide
crypto policies to enable or disable algorithms and protocols.
== Owner ==
* Name: [[User:Tmraz | Tomáš Mráz]]
* Email: tmraz(a)redhat.com
== Detailed Description ==
The crypto-policies package will be enhanced to allow system
administrators to modify the existing system-wide crypto policy levels
by removing or adding enabled algorithms and protocols. For example it
will be possible to easily modify the existing DEFAULT policy to
disable the SHA1 support or enable support for a national crypto
algorithm that is supported by the crypto libraries but is disabled in
the policies. System administrator will be able to add a simple
configuration file that will achieve this after calling the
update-crypto-policies command.
== Benefit to Fedora ==
This will enable advanced users of Fedora to adjust the
crypto-policies of the system to their particular needs and
requirements.
It will also enable using Fedora where the national crypto algorithms
are required without need to manually tinker with configurations of
various software components to enable the national crypto algorithms.
== Scope ==
* Proposal owners:
The design of the feature and prototype is already finished upstream.
We still need to convert the existing back-end policy generators to
the new framework and convert the existing policy definitions to the
new format. Then the crypto-policies package will be rebased to the
version with the custom crypto policies support included.
* Other developers: N/A (not a System Wide Change)
* Release engineering: 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 ==
No impact. The crypto policies will continue to work as expected and
worked before if a custom policy is not set.
== How To Test ==
This will be tested as part of the upstream crypto-policies testsuite.
== User Experience ==
Unless the user will choose to create and/or apply a custom crypto
policy on the system, there will be no noticeable user experience
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)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
The crypto-policies package was enhanced to allow system
administrators to modify the existing system-wide crypto policy levels
by removing or adding enabled algorithms and protocols. For example it
is now possible to easily modify the existing DEFAULT policy to
disable the SHA1 support or enable support for a national crypto
algorithm that is supported by the crypto libraries but is disabled in
the policies. This can be achieved by adding a simple configuration
file and calling the update-crypto-policies command.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/xfce-4.14
== Summary ==
Xfce desktop environment has version 4.13.x which is currently
available in Fedora. Significant work has been completed to migrate
the DE to GTK-3 completely. The obvious benefit to this migration is
the use of a modern and actively maintained toolkit.
Xfce 4.14 is a stable release with proven components, provide features
users. This change proposal is submitted to sync fedora packages with
the latest upstream releases.
== Owners ==
* Name: [[User:nonamedotc| Mukundan Ragavan]]
* Email: nonamedotc(a)fedoraproject.org
* Name: [[User:kevin| Kevin Fenzi]]
* Email: kevin(a)scrye.com
* Name: [[User:gerd| Gerd Pokorra]]
* Email: gerd(a)fedoraproject.org
== Detailed Description ==
This change migrates Xfce desktop environment (DE) to the latest
version provided by upstream developers. This is a near complete GTK-3
migration of the DE.
== Benefit to Fedora ==
Other GTK-based DEs such as cinnamon and MATE have already migrated to
using GTK-3 libraries. This change proposes to migrate the popular
Xfce DE to the latest GTK-3 based versions upstream developers have
released.
This change would result in fewer packages depending on the older
GTK-2 libraries and move Xfce to use a modern toolkit.
== Scope ==
* Proposal owners:
** Update core xfce packages to 4.14
** Rebuild plugins once core packages are build
* Other developers: N/A (not a System Wide Change)
== User Experience ==
* A fresh install should have fully functional Xfce DE
* Upgrade from Fedora 30 or older should show no visible changes to
the end users.
** GTK-3 applications will be better integrated
No special configuration or hardware needed.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Fedora 31 ships with Xfce 4.14.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis