The Fedora 32 deadline season is upon us! Here are the dates of
upcoming deadlines:
* 2019-12-25 Submission deadline for Changes requiring infrastructure changes
* 2019-12-31 Submission deadline for Changes requiring a mass rebuild
* 2019-12-31 Submission deadline for System-Wide Changes
* 2020-01-21 Submission deadline for Self-Contained Changes
As always, key schedule dates (and the rest of the schedule) are on
the schedule webpage at
https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Drop_Optical_Media_Criterion
= Drop Optical Media Release Criterion =
== Summary ==
Proposal to make all Fedora optical media non-blocking. This means
we'd stop blocking on bugs found during the installation of Fedora
from optical media (like CDs and DVDs). This doesn't mean that
installation from optical media would stop working, just that the
Fedora Release wouldn't be blocked on any issues that can pop up in
Fedora installation using this method. Installation from USB devices
will remain blocking.
== Owner ==
* Name: [[User:frantisekz| František Zatloukal]]
* Email: fzatlouk(a)redhat.com
== Detailed Description ==
We are currently blocking Fedora Release on bugs specific to
installation from optical media. It seems wise to believe that only a
fraction of user base installs Fedora from Optical Media rather than
USB drive. New computers and laptops are usually sold without CD/DVD
drives and installation from optical media takes longer and is prone
to errors more compared to the installation using USB drive.
This change would make following images non-blocking for installation
from optical media:
* <code>Fedora-Everything-netinst-x86_64-_RELEASE_MILESTONE_.iso</code>
* <code>Fedora-Workstation-Live-x86_64-_RELEASE_MILESTONE_.iso</code>
== Benefit to Fedora ==
Fedora QE Team and testers from community will have more time to test
parts of Fedora that are far more visible and exposed to end users.
Fedora QE Team would have more time to add and test additional
high-profile blocking deliverables (like Fedora Silverblue) in near
future.
Fedora Releases wouldn't be held by bugs found in corner case
installation method.
== Scope ==
* Proposal owners: Change [[Releases/32/ReleaseBlocking]] to indicate
we no longer block on optical media, change Validation Testing
Matrices
* Other developers: No involvement by other developers needed
* Release engineering: https://pagure.io/releng/issue/9097
* Policies and guidelines: No changes needed
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
No change for upgrades/compatibility
== How To Test ==
Testing not applicable (this change shouldn't result in any changes to
the distribution)
== User Experience ==
Users installing Fedora from optical media might hit some bugs and
might not be able to complete Fedora installation using Optical Media
at all. Such bugs will be treated like other non blocking bugs.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Revert changes to indicate we block on
optical media again
* Contingency deadline: Final Freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
N/A
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/LLVM-10
== Summary ==
Update all llvm sub-projects in Fedora to version 10.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 10, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang9.0 and llvm9.0 will be added to ensure
that packages that currently depend on clang and llvm version 9
libraries will continue to work.
== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM.
== Scope ==
* Proposal owners:
** Review existing llvm and clang compatibility packages and orphan
any packages that are no longer used.
** Request a f32-llvm side-tag from Release Engineering.
** Build llvm9.0 and clang9.0 into the side-tag.
** When the upstream LLVM project releases version 10.0.0-rc1
(2020-1-15), package this and build it into the side tag.
** Merge side-tag into rawhide prior to the f32 branch date.
** Continue packaging newer release candidates into rawhide and f32
until the final release is complete (~2020-2-26)
* Other developers:
** Maintainers of packages that depend on clang-libs or llvm-libs will
need to update their spec files to depend on the clang9.0 and llvm9.0
compatibility packages if they want to rebuild their package and it
does not work with LLVM 10 yet. The key point here is that spec file
changes are only needed if a package is going to be rebuilt after LLVM
10 is added to Fedora. The compatibility packages will ensure that
already built packages continue to work.
* Release engineering: [https://pagure.io/releng/issues/9099]
* Policies and guidelines: No policies or guidelines will need to be
updated as a result of this change.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This change should not impact upgradeability.
== How To Test ==
The CI tests for the llvm sub-packages in Fedora will be used to catch
regressions that might be potentially introduced by the update to LLVM
10.
== User Experience ==
Users will benefit from new features and bug-fixes in the latest
version of LLVM.
== Dependencies ==
This change can be made without updating any other packages. However,
as mention before, packages that need to use LLVM 9 will need to
update their spec file on their first rebuild after this change.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) If there are
major problems with LLVM 10, the compatibility package provide a way
for other packages to continue using LLVM 9. In the worst case, we
could always revert LLVM back to LLVM 9, but this would only happen if
their were an unprecedented amount of problems.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? None
== Documentation ==
Release notes will be added for this change.
== Release Notes ==
LLVM sub-projects in Fedora have been updated to version 10:
* llvm
* clang
* lld
* lldb
* compiler-rt
* libomp
* llvm-test-suite
* libcxx
* libcxxabi
* python-lit
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Stop-Shipping-Individual-Component-L…
== Summary ==
Remove the individual component libraries (e.g. libclangBasic.so,
libclangAST.so, etc.) from the clang-libs package. Packages that
depend on the clang libraries should instead link against
libclang-cpp.so.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
The individual component libraries will be removed from the clang-libs
package in favor of libclang-cpp.so (which is already present in
clang-libs). The component shared libraries enabled by the
BUILD_SHARED=ON CMake option are not supported as a distribution
configuration by the upstream project and only recommended for use by
clang developers.[1]
The libclang-cpp.so shared object was added in clang 9.0 and now gives
us an alternative shared library option that is supported by the
upstream project and makes it possible for Fedora packages to stop
using the component libraries.
[1] https://llvm.org/docs/CMake.html
== Benefit to Fedora ==
We will improve stability in Fedora by packaging a build configuration
that is supported by the upstream project. In addition,
libclang-cpp.so will provide more LTO optimization opportunities than
the component libraries if LTO is enabled in Fedora builds. Also, in
order to access the clang API with the component libraries, an
application might need to link with up to 37 different shared
libraries, replacing these with a single shared library will help
improve application start-up times.
== Scope ==
* Proposal owners:
** The proposal owner will ensure that that all packages that depend
on clang-libs are updated to use libclang-cpp.so.
** Once all dependent packages have been migrated, the clang package
will be updated to pass -DBUILD_SHARED=OFF to cmake when configuring.
* Other developers: The other maintainers will be responsible for
reviewing and approving changes to their packages.
* Release engineering: [https://pagure.io/releng/issues/9096]
* Policies and guidelines: No policies or guidelines will need to be
updated as a result of this change.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This change should not impact upgradeability.
== How To Test ==
This can be tested using existing CI tests or tests in the %check
section of spec files. The changes should not be visible to end users
so tests should behave exactly as they did before the change.
== User Experience ==
End users that develop applications using the clang libraries will
need to update their applications to use libclang-cpp.so instead of
the individual component libraries if they want to use libraries
shipped with Fedora. This may be inconvenient, but we don't want
users to continue using a configuration that is not supported by the
upstream project. Once this change is made though, the applications
will see the same benefits mentioned in the "Benefits to Fedora"
section.
End users using Fedora packages that depend on clang libraries will
not need to do anything different.
== Dependencies ==
The following packages depend on clang-libs and will need to be updated:
* bcc
* bpftrace
* castxml
* ccls
* clazy
* gnome-builder
* ispc
* kdevelop
* lldb
* mesa
* pocl
* qt-creator
* qt5-doctools
* shiboken2
* tinygo
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) If we are
unable to migrate all dependent packages in time, then the proposal
owner will postpone the final step of passing -DBUILD_SHARED_LIBS=OFF
to cmake when configuring clang until a future Fedora release. In this
case, packages that have already been migrated will continue to work,
since libclang-cpp.so is already included in the clang-libs package.
* Contingency deadline: Change Checkpoint: Completion deadline
* Blocks release? No
* Blocks product? None
== Documentation ==
Release notes will be added for this change.
== Release Notes ==
The individual component libraries (e.g. libclangBasic.so,
libclangAST.so, etc.) have been removed from the clang-libs packages.
Developers who want to link their application against the clang
libraries should link against libclang-cpp.so instead.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Greetings, all!
The elections for FESCo for Fedora 31 have concluded, and the results
are shown below.
FESCo is electing 5 seats this time.
A total of 273 ballots were cast, meaning a candidate
could accumulate up to 2184 votes (273 * 8).
The results for the elections are as follows:
# votes | name
- --------+----------------------
1490 | Miro Hrončok
1350 | Kevin Fenzi
1115 | Zbigniew Jędrzejewski-Szmek
879 | Fabio Valentini
877 | David Cantrell
- --------+----------------------
868 | Justin Forbes
813 | Randy Barlow
534 | Pete Walter
Congratulations to the winning candidates, and thank you all
candidates for running this elections!
For results of other elections, see the Community Blog post:
https://communityblog.fedoraproject.org/?p=8471
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Python3.9
Note that this is for Fedora *33*
== Summary ==
Update the Python stack in Fedora from Python 3.8 to Python 3.9.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: python-maint(a)redhat.com
== Detailed Description ==
We would like to upgrade Python to 3.9 in Fedora 33 thus we are proposing
this plan early.
See the upstream notes at [
https://www.python.org/dev/peps/pep-0596/#features-for-3-9 Features for
3.9] and [https://docs.python.org/3.9/whatsnew/3.9.html What's new in 3.9].
=== Important dates and plan ===
* 2019-06-04: Python 3.9 development begins
* 2019-11-19: Python 3.9.0 alpha 1
** Package it as {{package|python39}} for testing purposes
** Start the bootstrap procedure in Copr
** Do a mass rebuild against every future release in Copr
* 2019-12-16: Python 3.9.0 alpha 2
* 2020-01-13: Python 3.9.0 alpha 3
* 2020-02-11: Branch Fedora 32, Rawhide becomes future Fedora 33
** The earliest point when we can start rebuilding in Koji side-tag
* 2020-02-17: Python 3.9.0 alpha 4
* 2020-03-16: Python 3.9.0 alpha 5
* 2020-04-13: Python 3.9.0 alpha 6
* 2020-05-18: Python 3.9.0 beta 1
** No new features beyond this point
** The ideal point when we can start rebuilding in Koji
* 2020-05-30: Expected side tag-merge (optimistic)
* 2020-06-08: Python 3.9.0 beta 2
* 2020-05-18: Expected side tag-merge (realistic)
* 2020-06-29: Python 3.9.0 beta 3
* 2020-07-18: Expected side tag-merge (pessimistic)
* 2020-07-20: Python 3.9.0 beta 4
* 2020-07-22: Fedora 33 Mass Rebuild
** The mass rebuild happens with fourth beta. We might need to rebuild
Python packages later in exceptional case.
** If the Koji side-tag is not merged yet at this point, we defer the
change to Fedora 34.
* 2020-08-10: Python 3.9.0 candidate 1
** This serves as "final" for our purposes.
* 2020-08-11: Branch Fedora 33, Rawhide becomes future Fedora 34
* 2020-08-11: Fedora 33 Change Checkpoint: Completion deadline (testable)
* 2020-08-25: Fedora Beta Freeze
** If rebuild with 3.9.0rc1 is needed, we should strive to do it before the
freeze - there is a window of 2 weeks.
* 2020-09-14: Python 3.9.0 candidate 2
* 2020-09-15: Fedora 33 Beta Release (Preferred Target)
** Beta will likely be released with 3.9.0rc1.
* 2020-09-22: Fedora 33 Beta Target date #1
* 2020-10-05: Python 3.9.0 final
* 2020-10-06: Fedora 33 Final Freeze
** We'll update to 3.9.0 final using a freeze exception.
* 2020-10-20: Fedora 33 Preferred Final Target date
* 2020-10-27: Fedora 33 Final Target date #1
(From [https://www.python.org/dev/peps/pep-0596/#schedule Python 3.9
Release Schedule] and [
https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html Fedora 33
Release Schedule].)
The schedule is somewhat tight for Fedora 33, but Python's [
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
annual release cycle was adapted for Fedora], hence we have a better chance
of making it in time. In the future, it is expected that Python will be
upgraded on a similar schedule in every odd-numbered Fedora release.
Note that upstream's "release candidates" are frozen except for blocker
bugs. Since we can and will backport blocker fixes between Fedora and
upstream, we essentially treat the Release Candidate as the final release.
=== Notes from the previous upgrade ===
There are notes from the previous upgrade available, so this upgrade may go
smoother: [[SIGs/Python/UpgradingPython]]
== Benefit to Fedora ==
Fedora aims to showcase the latest in free and open source software - we
should have the most recent release of Python 3. Packages in Fedora can use
the new features from 3.9.
There's also a benefit to the larger Python ecosystem: by building Fedora's
packages against 3.9 while it's still in development, we can catch critical
bugs before the final 3.9.0 release.
== Scope ==
We will coordinate the work in a side tag and merge when ready.
* Proposal owners:
*# Introduce {{package|python39}} for all Fedoras
*# Prepare stuff in Copr as explained in description.
*# Retire {{package|python39}} from F32+
*# Update {{package|python3}} to what was in {{package|python39}}
*#* Mass rebuild all the packages that BR
{{package|python3}}/{{package|python3-devel}}/... (3000+ listed in [
http://fedora.portingdb.xyz/ Python 3 Porting Database for Fedora])
*# Reintroduce {{package|python38}} from Fedora 31. Update it to have all
fixes and enhancements from {{package|python3}} in Fedora 32 (or 33 before
this change)
* Other developers: Maintainers of packages that fail to rebuild during the
rebuilds will be asked, using e-mail and bugzilla, to fix or remove their
packages from the distribution. If any issues appear, they should be
solvable either by communicating with the respective upstreams first and/or
applying downstream patches. Also the package maintainers should have a
look at: [
https://docs.python.org/3.9/whatsnew/3.9.html#porting-to-python-3-9 Porting
to Python 3.9]. The python-maint team will be available to help with fixing
issues.
* Release engineering: [https://pagure.io/releng/issue/9046 #9046]
* Policies and guidelines: nope
* Trademark approval: nope
== Upgrade/compatibility impact ==
All the packages that depend on Python 3 must be rebuilt. User written
Python 3 scripts/applications may require a small amount of porting, but
mostly Python 3.8 is forward compatible with Python 3.9.
== How To Test ==
Interested testers do not need special hardware. If you have a favorite
Python 3 script, module, or application, please test it with Python 3.9 and
verify that it still works as you would expect. If the application you are
testing does not require any other modules, you can test it using
{{package|python39}} even before this change is implemented, in Fedora 30,
31 or 32.
In case your application requires other modules, or if you are testing an
rpm package, it is necessary to install the 3.9 version of the python3 rpm.
TODO: <del>Right now that rpm is available in copr, along with all other
python packages that build successfully with python 3.9. See
https://copr.fedorainfracloud.org/coprs/g/python/python3.9/ for detailed
instructions how to enable Python 3.9 copr for mock.</del>
Once the change is in place, test if you favorite Python apps are working
as they were before. File bugs if they don't.
== User Experience ==
Regular distro users shouldn't notice any change in system behavior other
than the Python 3 interpreter will be in version 3.9.
== Dependencies ==
3000+ packages depend on {{package|python3}}. See scope section.
== Contingency Plan ==
* Contingency mechanism: Do not merge the side tag with rawhide. If the
side tag has been merged and issues arise, that will justify a downgrade,
then use an epoch tag to revert to 3.7 version (never needed before)
* Contingency deadline: TBD
* Blocks release? Yes, we'd like to block Fedora 33 release on at least
3.9.0rc1
* Blocks product? See above
== Documentation ==
[https://www.python.org/dev/peps/pep-0596/ Python 3.9 Release Schedule]
[https://www.python.org/dev/peps/pep-0596/#features-for-3-9 Features for
3.9]
[https://docs.python.org/3.9/whatsnew/3.9.html What's new in 3.9]
[https://docs.python.org/3.9/whatsnew/3.9.html#porting-to-python-3-9
Porting to Python 3.9]
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis