It's been six months, and like clockwork, we release Fedora 30 today!
Thank you to the thousands of people who worked to bring this release
together. Fedora doesn't happen by magic: it happens because of you!
Read the official announcement at:
* https://fedoramagazine.org/announcing-fedora-30/
or just go ahead and grab it from:
* https://getfedora.org/
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot
== Summary ==
Create <code>gdb-minimal</code> package (without XML support, Python
support, Syntax Highlight and such) and switch to it in buildroot.
== Owner ==
* Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:sergiodj|Sergio
Durigan Junior]]
* Email: ignatenkobrain(a)fedoraproject.org, sergiodj(a)sergiodj.net
== Detailed Description ==
Create subpackage in <code>gdb</code> source package called
<code>gdb-minimal</code> that will contain 2 files:
* <code>/usr/libexec/gdb-minimal</code> — GDB executable built without
optional unneeded features
* <code>/usr/bin/gdb-add-index</code> — Executable script shared with
gdb-headless package (modified to fallback to gdb-minimal if exists)
debuginfo code in RPM needs just gdb-add-index and that one doesn't
need any syntax highlight or python plugins to work.
As of Apr 26, following packages would disappear from buildroot:
<pre>
boost-regex-1.69.0-6.fc30.x86_64
ctags-5.8-25.fc30.x86_64
gdbm-libs-1:1.18-4.fc30.x86_64
libbabeltrace-1.5.6-2.fc30.x86_64
libicu-63.1-2.fc30.x86_64
libipt-2.0-2.fc30.x86_64
python-pip-wheel-19.0.3-1.fc31.noarch
python-setuptools-wheel-40.8.0-1.fc30.noarch
python3-3.7.3-2.fc31.x86_64
python3-libs-3.7.3-2.fc31.x86_64
python3-pip-19.0.3-1.fc31.noarch
python3-setuptools-40.8.0-1.fc30.noarch
source-highlight-3.1.8-24.fc31.x86_64
sqlite-libs-3.27.2-3.fc31.x86_64
</pre>
== Benefit to Fedora ==
* Python 3 will disappear from buildroot (yes, it was there just because of GDB)
* RPM download size for buildroot preparation will go down from 101M to 85M
* installed buildroot size will go down from 439M to 350M
== Scope ==
* Proposal owners: Create a subpackage in gdb, Add <code>Suggests:
gdb-minimal</code> into rpm-build
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issue/8311 #8311]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== User Experience ==
Python 3 will disappear from buildroot, but nobody should have ever
relied on it since we have guidelines about that for long time:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#buildrequires
== 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)
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
Release status of Fedora 30 Final is NO-GO.
Due to open blocker bugs and the recentness of RC1, Fedora 30 Final
was declared "No-Go". We will reconvene at 1700 UTC on Friday, 26
April[1] to evaluate the status of RC2. If declared Go, we will
release on the preferred target date of 30 April. If declared No-Go,
we will meet again on Monday, 29 April to target a release date of
Thursday 2 May.
For more information, please see the minutes[2] from the Fedora 30
Final Go/No-Go meeting.
[1] https://apps.fedoraproject.org/calendar/Fedora%20release/2019/4/22/#m9521
[2] https://meetbot.fedoraproject.org/fedora-meeting-1/2019-04-25/f30-final-go_…
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
https://fedoraproject.org/wiki/Changes/Set_skip_if_unavailable_default_to_f…
== Summary ==
Dnf team wants to change a default setting for the repo option
`skip_if_unavailable` to `FALSE`.
== Owner ==
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmracek(a)redhat.com
== Detailed Description ==
Dnf team wants to change a default setting for the repo option
`skip_if_unavailable` to `FALSE`. The option is responsible for
behavior when metadata of a repository is unavailable. When it is set
to false, it will stop on the first unavailable repository with
raising an error. The default behavior could be overwritten by a
configuration of each repository or in dnf by configuration in
/etc/dnf/dnf.conf.
The behavior is not new, because it was used already by YUM, and the
behavior is really essential because all Fedora ropos are already
shipped with `skip_if_unavailable=FALSE`.
The change will be applied in libdnf library, and the changed behavior
will be visible for all direct and indirect users of the library: dnf,
microdnf, PackageKit, ... .
== Benefit to Fedora ==
It should provide a better security because some Important updates
from third-party repositories could be present in temporary
unavailable repository, but user can easily overlook it during `dnf
update` because the issue is reported as a warning.
== Scope ==
* Proposal owners:
** Backport the following upstream pull requests into the DNF stack on
Fedora: https://github.com/rpm-software-management/libdnf/pull/701
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/8307 #8307]
* Policies and guidelines: N/A
* Trademark approval: not needed for this Change
== How To Test ==
Edit .repo file in /etc/yum.repos.d/* and set an url that is not accessible.
Case 1:
No skip_if_unavailable in the repo file, in /etc/dnf/dnf.conf or
overwritten from commandline using `--setopt`.
Any command that requires available repositories like `dnf repoquery`
will fail due to an error `Error: Failed to synchronize cache for repo
'<repo_ID>'`
Case 2:
Set skip_if_unavailable=true in the repo file.
Any command that requires available repositories like `dnf repoquery`
will not fail due to missing metadata of the `<repo_id>`
== User Experience ==
Broken repositories are recognized early, enabling the users to act
upon them by double-checking their repository configuration or filing
bugs, instead of assuming no upgrades are available.
== Dependencies ==
Depend packages - dnf, microdnf, PackageKit
There are no changes on which completion of this change depends.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
The change requires a merge and a release of the pull-request
https://github.com/rpm-software-management/libdnf/pull/701
* Contingency deadline: Should be delivered before 2019-07-24.
* Blocks release? No
* Blocks product? No
== Documentation ==
https://dnf.readthedocs.io/en/latest/conf_ref.html
Update for documentation:
https://github.com/rpm-software-management/dnf/pull/1358
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
https://fedoraproject.org/wiki/Changes/RetirePython2
== Summary ==
The {{package|python2}} package and all its subpackages will be
removed from Fedora 32.
A legacy {{package|python27}} package for developers and users will
be provided.
All packages in Fedora that need Python 2 to run will be removed from
Fedora 32 regardless of their dependencies.
All packages in Fedora that need Python 2 to build will be removed
from Fedora 32 regardless of their dependencies.
Exceptions can be granted by FESCo.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: <mhroncok(a)redhat.com> <python-devel(a)lists.fedoraproject.org>
== Detailed Description ==
Python 2 is unsupported upstream since 2020-01-01. Packages dependent
on Python 2 are being removed from Fedora for several releases
already:
* [[Changes/Mass_Python_2_Package_Removal|Fedora 30 Mass Python 2
Package Removal]]
* [[Changes/F31_Mass_Python_2_Package_Removal|Fedora 31 Mass Python 2
Package Removal]]
Now, the Python maintainers have decided to pull the plug. The
{{package|python2}} package and all its subpackages will be retired
(read: removed) from Fedora 32 (Rawhide) as soon as Fedora 31 is
branched.
All packages depending on any python2 package will be removed. The
removal starts 2 weeks before the planned Fedora 32 Mass Rebuild.
Broken dependencies will not stop the removals.
Packages that Fail to Build From Source and prevent to remove Python 2
subpackages may end up with broken dependencies,
in cases where it is not desired, those packages will be retired instead.
The rules also apply to modules built for Fedora 32+.
The package removal will be executed in an automated fashion.
Removed packages that would block the upgrades to Fedora 32 will be
obsoleted from {{package|fedora-obsolete-packages}}.
=== The python27 package ===
Similarly to existing {{package|python36}}, {{package|python37}} etc.
packages, a {{package|python27}} package will be created.
This package is indented for Python developers who still need to
support the legacy version of Python.
This package is indented for users, who still need to use some
software depending on the legacy version of Python.
This package is not intended for other Fedora packages to be depended upon.
The {{package|python27}} package has several drawbacks compared to the
original {{package|python2}} package:
* it is "flat" - there are no subpackages, everything lives in one package
* there is no debug build (previously available as {{package|python2-debug}})
* there is no <code>/usr/bin/python</code> (note: there might be
already the case before this change)
* any special backwards compatible Provides are removed (this package
is not intended to be depended upon)
=== FESCo exceptions ===
We realize that there are some packages whose removal could seriously
hurt Fedora. FESCo can grant exceptions for packages to use the
{{package|python27}} as a runtime or build dependency.
The package maintainer is responsible to check the entire dependency
chain and they need to request exceptions for the entire list of
packages. For example, when seeking exception for the
{{package|chromium}} package, the request should contain
{{package|python-psutil}} and other dependent packages. (Yes, this is
tedious. Maintaining a Python 2 dependent package is a burden.)
The exception request must include a plan for migrating to Python 3.
Any non-essential dependency must be dropped. That includes optional
dependencies, test dependencies, optional subpackages etc.
Package that fail to get an exception when the removal starts (see
above) will be removed. Their importance for Fedora Release
Engineering, Fedora Infrastructure or any other body will not be
automagically respected; every package that needs Python 2 needs an
exception.
The change owners will send regular reminders to the package owners.
== Benefit to Fedora ==
Python 2 is past upstream End of Life since 2020-01-01. This changes
is generally crafted in a way that:
* it leaves Python developers an option to use it in case they still
need to support it
* it leaves Fedora users an option to use it in case they still need
it to run their (3rd party) software
* it leaves Fedora packagers an option to keep using it (complicated,
but possible)
While:
* it removes Python 2 software from Fedora that was only preserved so
far by inaction
Using Python 2 is dangerous. While the Fedora Python maintainers will
try to fix as many security bugs as possible, without the upstream
involvement this will be hard.
Python 2 is deprecated since Fedora 30. This change moves Python 2
from second class citizen to third class citizen.
== Scope ==
* Proposal owners:
** retire {{package|python2}}
** introduce {{package|python27}}
** remove all {{package|python2}} dependent packages that do not have
FESCo exceptions
** obsolete removed packages that break the upgrade path via
{{package|fedora-obsolete-packages}}
* Other developers:
** remove their {{package|python2}} dependent packages without exceptions
** get exceptions if needed
** fix broken dependencies
* Release engineering: [https://pagure.io/releng/issue/8306 #8306]
easeBlocking/Fedora{{FedoraVersionNumber|next}}|List of
deliverables]]: none
* Policies and guidelines: Python 2 packaging is against the
guidelines since Fedora 30. Python 2 packaging guidelines will be
removed from [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/
Python Appendix] (unless the FPC wants to keep them around until F31
EOL).
* Trademark approval: not needed for this Change
== Upgrade/compatibility impact ==
The majority of removed packages will be obsoleted and removed on upgrade.
Users needing Python 2 libraries will not find these packaged as RPMs.
They may install upstream versions using pip and virtualenv.
== How To Test ==
Try to update Fedora 30 or 31 to 32. No python2 packages should block
the upgrade.
Try to run Python 2 software via the {{package|python27}} package.
== User Experience ==
There will be close to zero Python 2 RPMs in Fedora repos. Users are
encouraged to switch to Python 3 and/or use Python 2 virtual
environments and pip for development.
== Dependencies ==
Ideally, all programs that use python2 would be switched to use
python3. Although we don't expect everything to be switched over, as
much as possible should be, so that the ripped remaining python2 set
is small as possible.
== Contingency Plan ==
* Contingency mechanism:
** In case of serious issues, FESCo can issue a general exception for
packages that would otherwise prevent Fedora 32 from being composed.
** If someone steps up to maintain Python 2 (including the full
ecosystem of packages now in Fedora), they can decide to discontinue
removing packages, revert this Change, or come up with another plan.
(Note that in this case, current maintainers will most likely orphan
many fundamental python2 packages.)
* Contingency deadline: Fedora 32 Beta
* Blocks release? in theory it should not, in practice, it may break
the release and hence it will block it until fixed
* Blocks product? all of them?
== Documentation ==
This page should serve as the documentation.
== Release Notes ==
TBD.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
Dear all,
Join us on irc.freenode.net in #fedora-meeting-1 for the Fedora 30
Release Readiness meeting. This meeting will be held on Thursday,
2018-04-25 at 19:00 UTC.
We will meet to make sure we are coordinated and ready for the release
of Fedora 30. Please note that this meeting will be held even if the
release is delayed at the Go/No-Go meeting on the same day two hours
earlier.
You may receive this message several times in order to open this
meeting to the teams and to raise awareness, so hopefully more team
representatives will come to this meeting. This meeting works best
when we have representatives from all of the teams.
For more information, see
https://fedoraproject.org/wiki/Release_Readiness_Meetings.
View the meeting on Fedocal:
https://apps.fedoraproject.org/calendar/meeting/9514/?from_date=2019-04-22
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
Greetings,
In the past, src.fedoraproject.org git repositories have been accessable
via the pagure[1] interface or via the cgit web interface.
We have been planning some changes to the way the backend git
repositories are stored on src.fedoraproject.org: from local bare repos
to repoSpanner[2] clustered and distributed repositories. This will
allow multiple frontends for that data, including sharing them with
git.centos.org.
This change however meant that cgit could no longer have access to
the bare git repositories and thus would no longer work. Please
adjust any workflows you may have that use cgit to use the
main pagure interface.
Thanks,
[1] https://pagure.io/pagure
[2] https://github.com/repoSpanner
Greetings.
I'm happy to announce that you can now use https to push commits
to src.fedoraproject.org. You will need to use 'fedpkg clone -a'
and have a session with a running browser to do the initial
authentication, but after that everything should be transparent.
Users who are not part of the 'packager' group can now use
this to push to forks of projects to create pull requests.
Please see https://fedoraproject.org/wiki/Infrastructure/HTTPS-commits
for more details.
We hope this support will allow more community members to
contribute along with allowing more flexibility to maintainers
who don't always have SSH access.
kevin
https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines
== Summary ==
The [[PackagingDrafts/Go| current Go packaging guidelines]] have been in a draft
state for several years now, and they do not reflect the
[[ More_Go_packaging|current practices ]] from the Go SIG. As a result of new
RPM macros developed by [[User:nim| Nicolas Mailhot]], the Go SIG wishes to
formally adopt new Go Packaging Guidelines, which aim at automation, reliability
and simplicity.
== Owner ==
* Name: [[User:eclipseo| Robert-André Mauchin]]
* Name: [[User:jcajka| Jakub Cajka]]
* Name: [[User:nim| Nicolas Mailhot]]
* Name: [[User:qulogic| Elliott Sales de Andrade]]
* Email: <golang(a)lists.fedoraproject.org>
== Detailed Description ==
Over 775 Go packages are currently residing in Fedora's repositories, yet no
formal guidelines have ever been approved. As a result, the various Go SPECs are
inconsistent and most often outdated. Moreover, the next version of Go, 1.13,
will introduce the concept of modules by default, which will completely change
how Go libraries are distributed. With the current state of our tooling, the Go
SIG is not prepared to face such a drastic change.
[[User:nim| Nicolas Mailhot]] has worked on a set of new RPM macros which
will allow us to disconnect the upstream Go tooling from the downstream
integration inside RPM. This will allow us to adapt easily to future upstream
changes without the need to rewrite our SPEC catalogue.
== Benefit to Fedora ==
* Simplicity: SPEC files are simpler, less error-prone
* Automation: the new macros computes packages definition, Requires,
Provides and has provision for the new automated BuildRequires
* Standardization of SPEC files across the Go library
* Drastic reduction of boilerplate and SPEC size
* Automatic removal of vendored code
* Ease of testing: all units tests are detected and run
* Ease of upkeep
* Ease of adaptation to upstream changes
== Scope ==
* Proposal owners:
** [https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/51
Get the last macros approved in ''redhat-rpm-config'']
** Get ''[https://pagure.io/golist golist]'', the tool detecting
dependencies, updated and split from the
''[https://src.fedoraproject.org/rpms/go-compilers/ go-compilers]''
package
** Release ''GOPATH'' directory ownership from the
''[https://src.fedoraproject.org/rpms/golang golang]'' package, so it
can be managed by the ''[https://pagure.io/go-rpm-macros
go-rpm-macros]'' package
** Get ''[https://pagure.io/go-rpm-macros go-rpm-macros]'' packaged and reviewed
** Retire ''[https://src.fedoraproject.org/rpms/go-srpm-macros
go-srpm-macros]'' and
''[https://src.fedoraproject.org/rpms/go-compilers/ go-compilers]''
** Port existing Go packages to the new macros (it probably won't be
finished by [[Releases/31 | Fedora 31]])
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines:
[https://pagure.io/packaging-committee/pull-request/883 Get the Go
packaging guidelines approved by the Packaging Committee]
== Upgrade/compatibility impact ==
No compatibility impact is expected. All the new macros are backward compatible
with the old ones.
== How To Test ==
The COPR [https://copr.fedorainfracloud.org/coprs/nim/macros-ng/ nim/macros-ng]
can be used to test the new macros on Rawhide. Sample SPEC files are available
in the FPC Guidelines proposal.
== User Experience ==
The user impact is minimal or nil. As a result of the simplification of SPEC
files, we may ship updated libraries more quickly, and it may be easier for new
contributors to package Go applications.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: If the required packages are not merged by
the deadline target, or if the Guidelines are not approved, we may
continue with our current set of non-approved practices. No other
impact is expected.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
* Blocks product? No
== Documentation ==
The FPC Guidelines proposal is available on
[https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/
eclipseo personal space].
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
FESCo has given us the go-ahead to turn zchunk metadata on again[1] for
the F30 fedora repository after the librepo segmentation fault bug[2]
was fixed. An updated librepo[3] was built a week ago and was pushed
to stable five days ago, so most beta users should have the new
version.
If you're using F30 and have librepo-1.9.6-1.fc30, please update to
librepo-1.9.6-2.fc30 as soon as possible! If you don't, you will once
again get a segmentation fault when running dnf.
If you find yourself getting a segmentation fault when running dnf on a
system with librepo-1.9.6-1.fc30, you can temporarily work around it by
doing the following:
1. Edit /etc/dnf/dnf.conf and add the following line:
zchunk=False
2. Run:
dnf update librepo
Verify that you got librepo-1.9.6-2.fc30 or later in the update
3. Remove the 'zchunk=False' line you added to /etc/dnf/dnf.conf
4. Run:
dnf update
At this point, dnf should download the repository metadata without any
segmentation faults, and any further repository metadata downloads
should be significantly smaller.
Jonathan
1. https://pagure.io/fesco/issue/2116
2.
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…
3. https://bodhi.fedoraproject.org/updates/FEDORA-2019-07c3e09858
Greetings.
This is a periodic reminder that we have some test instances setup for
package maintainers. Please see:
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintaine…
for more information.
Additionally, I have just added 2 aarch64 instances (running Fedora 29).
I hope folks will find them useful.
kevin
There will be an outage starting at 2019-04-09 16:00 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 '2019-04-09 16:00UTC'
Reason for outage:
Major upgrade to Taskotron
Affected Services:
Taskotron
Bodhi (displaying results)
Greenwave
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/7686
Please join #fedora-admin or #fedora-noc on irc.freenode.net or add
comments to the ticket for this outage above.
Fedora 30 Beta Released
----------------------------------
We're excited to announce the release of Fedora 30 Beta.
A short list of highlights:
* New desktop environment options - DeepinDE and Pantheon Desktop join
GNOME, KDE Plasma, Xfce, and others
* DNF performance improvements
* The Workstation edition of Fedora 30 Beta features GNOME 3.32
* And more...
For more details about the release, read the full announcement at
* https://fedoramagazine.org/announcing-the-release-of-fedora-30-beta/
or look for the prerelease pages in the download sections at
* https://getfedora.org/
Since this is a Beta release, we expect that you may encounter bugs or
missing features. To report issues encountered during testing, contact the
Fedora QA team via the mailing list or in #fedora-qa on Freenode.
Regards,
Mohan Boddu
Fedora Release Engineering.
https://fedoraproject.org/wiki/Changes/GatingRawhidePackages
Note that this was previously submitted as "Gating Rawhide - Single
package updates":
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
== Summary ==
We want to gate packages on test results before they can land in
rawhide. This will reduce the amount of broken dependency,
uninstallable packages and broken composes leading to a more stable
rawhide as well as less work on the infrastructure and rel-eng teams
to keep composes working.
== Owner ==
* Name: [[User:pingou|Pierre-Yves Chibon]]
* Email: pingou - pingoured.fr
People who are/will be involved in this:
* Coordinator: [[User:pingou|Pierre-Yves Chibon]]
* Bodhi: [[User:bowlofeggs|Randy Barlow]], [[User:abompard|Aurélien
Bompard]] and [[User:cverna|Clément Verna]]
* koji: [[User:mizdebsk|Mikolaj Izdebski]] and [[User:mikem|Mike McLean]]
* fedpkg/rpkg: [[User:cqi|Chenxiong ]] and [[User:lsedlar|Lubomír Sedlář]]
* Fedora CI: [[User:dperpeet|Dominik Perpeet]]
== Detailed Description ==
Rawhide is an unique place in the Fedora eco-system. It is the only
place where large changes and rebuilds can be done. In stable Fedora
releases, the rebuilds of large sets of packages is discouraged by the
packaging guidelines, so the ratio of number of updates in bodhi which
a single build vs multiple builds (95% to 5%) is not reflective of the
reality of the rawhide ecosystem.
The basic principal of this proposal is to provide an environment in
which packages can be built and tested without affecting other
packages.
When considering gating rawhide package updates on test results, we
need to consider two workflows: single build updates, multi-builds
updates. For single build, the easiest solution is to provide a
dedicated koji tag in which these packages are built and where they
will wait for their tests to pass before they can enter the buildroot.
For multi-builds, the solution will be to rely on side-tags in koji.
These side-tags are basically tags created by the packager and
available to them to do their work, in this case rebuild all the
packages desired. The side-tag can then sent to the test system as
being one unit of change.
To use a, now well-known, analogy, a single-build update is like
sending a commit to a mailing list, it waits there to be reviewed and
tested before being merged into the main repository. Multi-build
updates are like pull-requests, they can contain one or more builds
and which are reviewed and tested all together as one change before
being merged.
Within this proposal, we aim at building the infrastructure allowing
to gate packages in rawhide. The goal is for packages to go through
bodhi, be tested and if the tests pass, land in the rawhide buildroot
as they do today. In the simplest case, the packager workflow will not
be affected by this proposal, less simple situation will require
adjustements to the packager workflow that we would like to try to be
as minimal as possible.
We do not aim at making any tests mandatory as part of these
proposals. Once packages gating is in place it will be up to the
community and likely FESCo to decide if they would like to enforce
some rules on all packages and which ones.
Note that this proposal completes previous initiative such as
[[Changes/NoMoreAlpha]].
=== Workflows ===
<gallery>
Single_package_GatingRawhide_bodhi.png|Single package update with gating
GatingRawhide_MultiplePkgs_bodhi.png|Multi-packages update with gating
</gallery>
== Benefit to Fedora ==
* As more packagers opt-into gating and add tests to their packages,
rawhide becomes more stable
* More stable rawhide will lead to easier composes and a smoother
release process
* Ability to use chain-build in rawhide and stable releases
== Scope ==
The scope of this work is adding a mechanism to gate builds/updates
before they enter the rawhide buildroot (and thus become accessible to
others) so broken packages are kept out and cannot affect other
packages or the compose until they are fixed by their maintainers.
'''The CI system, the tests and the decision on which tests are used
to gate upon are out of scope for the present document.'''
* Proposal owners: pingou will be coordinating the work among the
different stack holders
* Other developers:
** Bodhi developers: Implement the needed changes
** koji developers: Implement the needed changes
** fedpkg/rpkg developers: Implement the needed changes
** infrastructure: deploy the new version of bodhi and koji
* Release engineering: [https://pagure.io/releng/issue/8183 #8183]
* Policies and guidelines: Once the entire system is in place, FESCo
may want to set a policy on distribution-wide gating (ie: tests that
would be enforced for all packages in the distributions). This is
however out of scope of this proposal.
* Trademark approval: N/A (not needed for this Change)
=== Application impacted ===
==== Bodhi ====
* A message-bus listener will automatically create a bodhi update for
each package built in the rawhide-gated tag.
* A message-bus listener will automatically push bodhi updates created
for rawhide that have passed CI (the decision being announced by
Greenwave).
* A message-bus listener will automatically comment on bodhi update
about update in greenwave's decision
** This will notify users about the test results and the corresponding
gating status.
* bodhi will support creating a new update from a side-tag instead of
a list of builds.
==== Koji ====
* A koji plugin will allow packagers to create new side-tags
* How side-tags are created will be optimized so they do not take
hours to be available to the user requesting them
==== fedpkg/rpkg ====
* The command: `fedpkg side-tag create` will be added to create a new
side-tag in koji for this user using the new plugin
* The command: `fedpkg side-tag merge` will be added to create a bodhi
update corresponding from this side-tag
** Alternatively: Expand the existing `fedpkg update` command to add
support for creating a new update from a side-tag
==== Greenwave / WaiverDB ====
Nothing should change for these tools but we will have to confirm this
and test in staging that they behave as expected.
==== CI system ====
Nothing should change for the CI system but we will have to confirm
this and test in staging that they behave as expected.
== Upgrade/compatibility impact ==
N/A
== How To Test ==
=== Single build ===
==== With opting in into gating ====
# Add tests to a package you maintain in Fedora using the
[https://docs.fedoraproject.org/en-US/ci/quick-start-guide/
ci/quick-start-guide] documentation (see the full
[https://docs.fedoraproject.org/en-US/ci/ CI documentation] for more
information).
# Update your package in rawhide
# Ensure that the bodhi update is automatically created
# Check that the tests have properly ran (see the Tests tab in the bodhi update)
# Ensure that the bodhi update went through to rawhide once the tests passed
If one or more tests failed and you wish to waive them
# Waive the failing tests using `bodhi updates waive <id>` see `bodhi
updates waive --help` for more information
==== Without opting in into gating ====
# Ensure your package does not have a `gating.yaml` in its dist-git repository
# Build your package in rawhide as you do today
# Ensure that the bodhi update is automatically created
# Ensure that the bodhi update goes through to rawhide automatically
=== Multi-builds ===
# Add tests to a package you maintain in Fedora using the
[https://docs.fedoraproject.org/en-US/ci/quick-start-guide/
ci/quick-start-guide] documentation (see the full
[https://docs.fedoraproject.org/en-US/ci/ CI documentation] for more
information).
# Request a new side-tag in koji for your rebuilds
# Update your packages in this side-tag
# Request for this side-tag to be merged either using fedpkg or
bodhi's UI (create a new update from a side-tag)
# Check that the tests have properly ran (see the Tests tab in the bodhi update)
# Ensure that the bodhi update went through to rawhide once the tests passed
# Check that the side-tag was correctly cleaned afterward
==== Without opting in into gating ====
# Ensure all your packages do not have a `gating.yaml` in its dist-git
repository
# Build your packages in rawhide as you do today
# Ensure that the bodhi updates are automatically created
# Ensure that the bodhi updates go through to rawhide automatically
== User Experience ==
=== Musts ===
Here below are the list of requirements for this proposal:
* Packagers must be notified when the update corresponding to their
build(s) passes or fails CI
* Packagers must be able to see what is blocking an update (ie missing
requirements/test results)
* Packagers must be able to re-trigger a test run (via either an UI or a CLI)
* Packagers must be able to waive false-negative (via either an UI or a CLI)
=== Nice to have ===
Here below is a list of ideas that would make the user experience more
friendly but will not be part of the initial release:
* Packagers would like to follow the progress of the tests
** This could be implemented by notifying the packagers when a test
run starts and provide an URL where they could see and follow them
* Packagers would like to be able to re-trigger a test run from an UI and a CLI
* Packagers would like to be able to waive false-negative from an UI and a CLI
* Packagers would like the ability to transform a bodhi update
automatically created for a single build into a side-tag-specifi bodhi
update
** This would allow the workflow where a packager makes a build, which
fails CI because another package needs to be rebuilt as well. The
packager can then convert the bodhi update into a side-tag based
update, this would create the corresponding side-tag and move the
existing build into it, allowing the packager to do the missing
rebuilds before telling bodhi to process the update. This is entirely
doable by hand, which is why this feature while convenient is
considered a nice to have
* Packagers would like fedpkg chain-build to create the corresponding
side-tag automatically
=== Single build update ===
fedpkg clone rpms/foobar
cd foobar/
vim foobar.spec
git commit -am "Git commit message"
fedpkg build
If the CI tests pass, the package will land in rawhide, if they fail the user
will be able to go to bodhi to see what failed and why as well as waiving the
failed tests if needed.
=== Multi builds with gating ===
fedpkg clone rpms/foobar
cd foobar/
fedpkg side-tag create foo1.2
vim foobar.spec
git commit -am "Update of foobar to update foo to 1.2"
fedpkg push
fedpkg build --target=user_foo1.2
cd ..
fedpkg clone rpms/foobaz
cd foobaz
vim foobaz.spec
git commit -am "Update of foobaz to update foo to 1.2"
fedpkg push
fedpkg build --target=user_foo1.2
cd ..
fedpkg clone rpms/foo
cd foo
vim foo.spec
git commit -am "Update foo to 1.2"
fedpkg push
fedpkg build --target=user_foo1.2
fedpkg side-tag merge foo1.2
== Dependencies ==
* Bodhi
* koji
* fedpkg
== Contingency Plan ==
We can keep doing rawhide as we are doing it today.
== Documentation ==
To be written/updated
List of documentation pages to update:
* https://fedoraproject.org/wiki/Updates_Policy
* https://fedoraproject.org/wiki/Package_maintenance_guide
* https://fedoraproject.org/wiki/Package_update_HOWTO
* https://docs.fedoraproject.org/en-US/packaging-guidelines/
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him