https://fedoraproject.org/wiki/Changes/fedora-change-wrangler
= Track Changes in Taiga =
The Motivation for this proposal is to propose using the Taiga
instance at teams.fedoraproject.org for Change processing.
[[User:Bcotton/UsePagureForChanges|Using Pagure]] was previously
proposed for this. The new Change Processing workflow aims to simplify
the process to improve visibility and ease of management.
== Summary ==
The current process allows contributors to propose changes in upcoming
Fedora releases. However, the management of those feature proposals is
cumbersome and requires several manual steps. This introduces more
opportunity for error and reduces the time available to the Change
Wrangler for more valuable contributions to Fedora. In particular, the
current process includes artifacts and discussion in the Fedora Wiki,
on mailing lists, FESCo tickets, Bugzilla tickets, and Docs tickets.
The current process is cumbersome with several manual steps,this
introduces more opportunity for error and reduces the time available
for the Change Wrangler.
A Cli Tool Written in Python that interacts with Taiga,Pagure and
Bugzilla.Functionality includes
Promoting,announcing,submitting,accepting and updating the changes
across the three platforms and over mailing list.
The new process will consolidate much of the information in
Taiga.Proposed Changes will be submitted as an issue in Taiga. The
description of the Issue will include the content with few exceptions:
* System-Wide or Self-Contained change will be indicated by a binary
in the issue metadata
* Fedora release will be indicated by a milestone in the issue metadata
* Change status will be indicated by a list selection in the issue metadata
== Owner ==
* Name: [[User:Pac23| Manas Mangaonkar]]
* Email: manasmangaonkar(a)gmail.com || pac23(a)fedoraproject.org
* Name: [[User:Bcotton | Ben Cotton]]
* Email: bcotton(a)redhat.com
== Detailed Description ==
As Part of GSoC 2019 the fedora-change-wrangler tool will be developed
to smooth out the workflow,reduce Manual Work involved for both the
Contributors and the Change-Wrangler(FPgm). The tool makes it easy by
covering all the functionality required for the process of moving
forward proposals.
The tool will be developed using Python 3.6+ and will interact with
Taiga/Pagure/Bugzilla via their API and the Mailing List via SMTP.
The General Workflow would be :
1. Change Owner opens an issue and fills in the fields. When they are
ready to submit the Change proposal, they set the status to "Ready
for Wrangler".
2. The Change Wrangler (FPgM) reviews the proposal. If it is
incomplete, they set the status back to "New" and inform the Change
Owner of what's needed. If it is ready to process, then...
Functionality covered
1. Promote
* The issue will be promoted to a user story in taiga,copies the
contents of the custom fields from the issue to the user story. Closes
the issue.
2. Announce
* The tool would have the functionality to enable announcing the
change proposal to devel and devel-announce lists using smtp. It will
also automatically change the story status to announced.
3. fesco-submit
* Allowing creation of a new issue in the FESco Pagure repo directly
from the command line.
4. Accept
* Once the changes are accepted the change-wrangler can create a
tracking bug in Bugzilla along with release notes on Pagure.THe status
of the user story is updated to accepted aswell.
5. Update
* Status can be changed to testable if BZ is "Modified" and to
Complete is BZ is "ON_QA"
6. Creation of Report
* The user can create a report to provide quick view of changes and
their status. It can be in wiki or Html form.
Techstack:
* Python3.6+
* SMTP
* Taiga/Pagure/Bugzilla API's
* Nano/Gedit/Vi ( Inbuilt support to edit text)
* Kerberos(For authentication)
The current sample arg created looks like this [ change-tool convert
--taiga <issue no> <issue no> ] . The advantage of this the Manager
would be able to specify unlimited no of issues to change at once in a
single command using the issue no in taiga to convert to user story.
== Benefit to Fedora ==
The proposed change will make the change-process easier for
everyone.Everyone would be able to see them in one place with
status,id filters. The current wiki process can be bit difficult for
formatting,having defined fields would mean easy access without the
cumbersome wiki edits.
Since changes would be submitted in Issue format on
Taiga,pre-submission discussions would be available thus getting
suggestions/feedback at the first stage itself would be easy for
everyone involved.
== Scope ==
* Proposal owners:
I will be working with the Change-Wrangler(Ben Cotton) throughout the
summer to create this tool from scratch.
* Other developers: N/A (not a System Wide Change)
* Release engineering:(no release engineering impact is expected)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No visible Impact is expected.
== Dependencies ==
No other packages depend on this.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
Enough buffer time has been allocated to complete this during the GSoC period.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hi everyone!
I'm starting a Minimization Objective [1] focusing on minimising the
installation size of some of the popular apps, runtimes, and other pieces
of software in Fedora.
And there is a new Minimization Team [2] forming. Members of the team will
consult and work with Fedora maintainers, develop tooling and services,
generate reports showing the status of the Fedora ecosystem and a
comparison with other ecosystems, etc. The goal is to build an environment
where it's easy for our maintainers to keep things small over time, it's
not just a one-off effort. Please see the Action Plan [3] for more details.
Want to become a member? Let me know!
Cheers!
Adam
[1] https://docs.fedoraproject.org/en-US/minimization/
[2] https://docs.fedoraproject.org/en-US/minimization/team/
[3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
--
Adam Šamalík
---------------------------
Senior Software Engineer
Red Hat
https://fedoraproject.org/wiki/Changes/EnableSysctlPingGroupRange
(Note this change proposal was originally submitted before the
deadline, but was delayed due to some discussion between the change
owner and change wrangler)
== Summary ==
Enable the Linux kernel's <code>net.ipv4.ping_group_range</code>
parameter to cover all groups.
== Owner ==
* Name: [[User:rishi|Debarshi Ray]]
* Email: debarshir(a)redhat.com
== Detailed Description ==
Enable the Linux kernel's <code>net.ipv4.ping_group_range</code>
parameter to cover all groups. This will let all users on the
operating system create ICMP Echo sockets without using setuid
binaries, or having the <code>CAP_NET_ADMIN</code> and
<code>CAP_NET_RAW</code> file capabilities.
== Benefit to Fedora ==
This makes <code>ping</code> work inside rootless [https://podman.io/
Podman] containers. Currently it doesn't.
When the Linux kernel's <code>net.ipv4.ping_group_range</code>
parameter is enabled for a group, users in that group can send ICMP
Echo packets without using setuid binaries, or having the
<code>CAP_NET_ADMIN</code> and <code>CAP_NET_RAW</code> file
capabilities. This works by using
[http://man7.org/linux/man-pages/man7/icmp.7.html ICMP Echo] sockets
instead of the more generic, and easier to abuse,
[http://man7.org/linux/man-pages/man7/raw.7.html raw] sockets. For
Fedora, this means that the file capabilities can be removed from the
<code>ping</code> binary.
This is good for OSTree based Fedora variants like Silverblue, where
development environments are often set up using rootless Podman
containers with helpers like [https://github.com/debarshiray/toolbox
Toolbox]. At present, <code>ping</code> doesn't work in those
environments, and it's inconvenient to not be able to use such a basic
network utility inside a development set-up.
== Scope ==
* Proposal owners: Enable <code>net.ipv4.ping_group_range</code> by
adding it to one of the files shipped by the sytemd RPM in
<code>/usr/lib/sysctl.d</code> or by creating a new file shipped by
the podman or toolbox RPMs.
[https://github.com/systemd/systemd/pull/13141 Here] is an upstream
pull request against systemd.
* Other developers: Once this change is in place, the file
capabilities should be removed from the <code>ping</code> binary
because they would no longer be necessary. However, it's not a
requirement for implementing this change.
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Systems with a previous version of Fedora won't need manual
intervention. They will inherit this change when updated.
== How To Test ==
On a Fedora system containing this change, the following commands should work:
<pre>
$ podman run -it --rm registry.fedoraproject.org/fedora:latest
...
# dnf -y install iputils
...
# ping fedoraproject.org
...
</pre>
== User Experience ==
Users of rootless Podman, including those developing on Silverblue
inside Toolbox containers, would now be able to use <code>ping</code>.
Earlier, they weren't able to.
== Dependencies ==
N/A (not needed for this Change)
== Contingency Plan ==
* Contingency mechanism: If <code>net.ipv4.ping_group_range</code>
isn't enabled then status quo will be maintained. No explicit action
needs to be taken. Note that the <code>ping</code> binary should not
be touched until this change is complete. Only then should be the file
capabilities removed.
* Contingency deadline: N/A (not needed for this Change)
* Blocks release? No
* Blocks product? No
== Documentation ==
There's no upstream documentation. There's some discussion on
[https://github.com/systemd/systemd/pull/13141 this] systemd pull
request.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Good Morning Everyone,
TL;DR: On July 24th we will turn on the first phase of Rawhide package gating,
for single build updates.
In a later phase, Rawhide updates that contain multiple builds will also be
enabled for gating. Our goal is to improve our ability to continuously turn out
a useful Fedora OS. So we hope and expect to get opt-in from as many Fedora
package maintainers as possible, including maintainers of the base OS. But this
phase of gating remains opt-in, and should not affect packagers who choose for
now not to opt in.
Last April FESCo approved a change proposal[1] allowing to gate Rawhide packages
based on test results. The proposal included gating updates with only a single
build as well as updates with multiple builds. It was designed to cause minimal
to no interference with the current workflow of packagers who do not opt-in.
The team has been working hard on this proposal, and decided to do a phased
roll-out of this change, so that we can gather feedback as early as possible
from the packagers interested in testing this workflow without impacting
everyone.
On July 24th, we plan to turn on the first phase of this change.
What does it mean for us as packagers?
--------------------------------------
When you run `fedpkg build` on Rawhide, your package will be built in a new koji
tag (which will be the default target for Rawhide). The package will be picked
up from this koji tag, signed and moved onto a second tag. Bodhi will be
notified by koji once this new build is signed and will automatically create an
update for it (you will be notified about this by email by bodhi directly) with
a “Testing” status. If the package maintainer has not opted in into the CI
workflow, the update will be pushed to “Stable” and the build will be pushed
into the regular Rawhide tag, making it available in the Rawhide buildroot, just
as it is today.
If the package maintainer has opted in into the CI workflow, the creation of the
update will trigger the CI pipeline which will send its results to resultsdb,
triggering greenwave to evaluate if all the required tests have passed or not,
thus allowing the update to go through the gate or not.
This is the first roll-out of this gating change, and so there may be additional
tuning and fixes until things are as smooth as we want them to be. With this
release we are looking for feedback on what can be improved. We have a dedicated
team working on this project and we will be taking your feedback into account to
improve the experience.
Small FAQ:
--------------
But I do not want to use gating!
While we believe CI and gating will ultimately help making a better Fedora,
there is nothing enforced at this point. Keep packaging as you do now!
How do I enroll?
Great! We’re glad to see such enthusiasm! You can find the instruction in the
docs on how to enable gating: https://docs.fedoraproject.org/en-US/ci/gating/
It does not work!
Bugs will be bugs. This is the first roll-out of this change, and more will
come. This rollout lets us gather feedback and iterate on the approach in an
open source fashion.
If you did not opt-in and you can’t do your packaging work as you used to,
please file a infrastructure ticket, since it’s likely a bug:
https://pagure.io/fedora-infrastructure/new_issue?title=[CI]
If you did opt-in and something in the gating of your update doesn’t work (for
example, CI ran but its results aren’t being considered, waiving didn’t work…),
file an infrastructure ticket:
https://pagure.io/fedora-infrastructure/new_issue?title=[CI]
If you opted-in and the tests don’t run the way you expect, file a fedora-ci
ticket: https://pagure.io/fedora-ci/general/new_issue
I enrolled but now I want to step out for some reasons
:sad trombone:
We hope you reported all the issues you’ve found/faced and are helping us
resolving them.
In the meanwhile, you can simply remove the gating.yaml file you’ve added in
your git repo and that should be enough to make greenwave ignore your package.
Want to know more? Your question isn’t here? Check our documentation on
rawhide gating: https://docs.fedoraproject.org/en-US/rawhide-gating/ [2]
We’ll keep it up to date as we face or solve questions.
Pierre
For the Rawhide package gating team
[1] https://pagure.io/fesco/issue/2102
[2] At the time of writing this, it looks like the website is having some
difficulties build the new version of the docs. This should get resolved in the
coming hours, sorry for the inconvenience.
(If only it had CI... :-))
https://fedoraproject.org/wiki/Changes/F31Boost170
== Summary ==
This change brings Boost 1.70 to Fedora. This will mean Fedora ships
with a recent upstream Boost release.
== Owner ==
* Name: [[User:jwakely| Jonathan Wakely]]
* Email: jwakely(a)redhat.com
== Detailed Description ==
The aim is to synchronize Fedora with the most recent Boost release.
Because ABI stability is one of explicit Boost non-goals, this entails
rebuilding of all dependent packages. This has also always entailed
yours truly assisting maintainers of client packages in decoding
cryptic boost-ese seen in output from g++. Such care is to be expected
this time around as well.
The equivalent changes for previous releases were
[[Changes/F30Boost169|Fedora 30 Change]], [[Changes/F29Boost167|Fedora
29 Change]], [[Changes/F28Boost166|Fedora 28 Change]],
[[Changes/F27Boost164|Fedora 27 Change]], [[Changes/F26Boost163|Fedora
26 Change]], [[Changes/F25Boost161|Fedora 25 Change]],
[[Changes/F24Boost160|Fedora 24 Change]],
[[Changes/F23Boost159|Fedora 23 Change]] and
[[Changes/F22Boost158|Fedora 22 Change]].
== Benefit to Fedora ==
Fedora 30 includes Boost 1.69, but the latest upstream release, Boost
1.70, was released on April 12th, 2019.
Fedora will stay relevant, as far as Boost clients are concerned.
Boost 1.70 brings two new components:
* [https://www.boost.org/libs/outcome/ Boost.Outcome], A set of tools
for reporting and handling function failures in contexts where
<i>directly</i> using C++ exception handling is unsuitable, from Niall
Douglas.
* [https://www.boost.org/libs/histogram/ Boost.Histogram], Fast and
extensible multi-dimensional histograms with convenient interface for
C++14, from Hans Dembinski.
== Scope ==
* Proposal owners:
** Build will be done with Boost.Build v2 (which is the
upstream-sanctioned way of building Boost)
** Request a "f31-boost"
[https://docs.pagure.org/releng/sop_adding_side_build_targets.html
build system tag]
([http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html
discussion]): https://pagure.io/releng/issue/8061
** Build boost into that tag (take a look at the
[http://koji.fedoraproject.org/koji/buildinfo?buildID=606493 build
#606493] for inspiration)
** Post a request for rebuilds to fedora-devel
** Work on rebuilding dependent packages in the tag.
** When most is done, re-tag all the packages to rawhide
** Watch fedora-devel and assist in rebuilding broken Boost clients
(by fixing the client, or Boost).
* Other developers:
** Those who depend on Boost DSOs will have to rebuild their packages.
Feature owners will alleviate some of this work as indicated above,
and will assist those whose packages fail to build in debugging them.
* Release engineering: [https://pagure.io/releng/issue/8500] (a check
of an impact with Release Engineering is needed)
* Policies and guidelines:
** Apart from scope, this is business as usual, so no new policies, no
new guidelines.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
* No impact on system upgrade (no removed subpackages this time).
* No manual configuration or data migration needed.
* Some impact on other packages needing code changes to rebuild.
Historically this hasn't been too big of a problem and could always be
resolved before deadline.
== How To Test ==
* No special hardware is needed.
* Integration testing simply consists of installing Boost packages
(<code>dnf install boost</code>) on Fedora and checking that it does
not break other packages (see below for a way to obtain a list of
boost clients).
== User Experience ==
* Expected to remain largely the same.
* Developers building third-party software on Fedora may need to
rebuild against the new Boost packages, and may need to adjust their
code if the new Boost release is not source-compatible.
== Dependencies ==
Packages that must be rebuilt:
<code>$ dnf repoquery -s --releasever=rawhide --whatrequires
libboost\* --disablerepo=* --enablerepo=fedora | sort -u</code>
All clients:
<code>$ dnf repoquery --releasever=rawhide --archlist=src
--whatrequires boost-devel --disablerepo='*'
--enablerepo=fedora-source</code>
== Contingency Plan ==
* Contingency mechanism: Worst case scenario is to abandon the update
and simply ship F31 with Boost 1.69, which is already in rawhide.
* Contingency deadline: We will know whether the change can be made
once the rebuilds in the side tag are done, which will be July 2019,
ideally before the mass rebuild.
* Blocks release? No
* Blocks product? None
== Documentation ==
* https://www.boost.org/users/history/version_1_70_0.html (released on
12 April 2019)
* https://www.boost.org/development/index.html
== Release Notes ==
Boost has been upgraded to version 1.70. Apart from a number of bug
fixes and improvements to existing libraries, compared to Fedora 30,
this brings:
* New header-only components: [https://www.boost.org/libs/outcome/
Boost.Outcome] and [https://www.boost.org/libs/histogram/
Boost.Histogram]
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/AArch64_Xfce_Desktop_image
== Summary ==
Add an AArch64 Xfce Desktop image to deliverables in Fedora 31.
== Owner ==
* Name: [[User:pwhalen| Paul Whalen]]
* Email: pwhalen(a)fedoraproject.org
* Responsible WG: ARM SIG
== Detailed Description ==
We currently offer Workstation, Minimal and Server images for use with
AArch64 Single Board Computer's (SBC's). We would like to add a
lighter weight desktop image for hardware that lacks the ability to
run accelerated desktops.
An initial set of supported devices:
* Pine64
* Raspberry Pi 3/4
* 96boards HiKey
* 96boards Dragonboard 410c
== Benefit to Fedora ==
Better user experience and an additional desktop choice for AArch64 SBC's.
== Scope ==
* Proposal owners: The ARM SIG will make the kickstart changes needed
to add the desktop images to the compose.
* Other developers: N/A
* Release engineering: Enable building of the AArch64 XFCE desktop
image. Small tweaks may be required to the pungi configs or fedora
kickstarts but those will be completed by the SIG and sent as pull
requests. Issue[https://pagure.io/releng/issue/8556 #8556]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
No upgrade compatibility required, this is a new image variant.
== How To Test ==
Testing can be completed on any supported AArch64 SBC using the
existing arm-image-installer. Any additional instructions will be
added to the ARM installation documentation.
== User Experience ==
Users will have increased choice in desktop offerings for AArch64
SBC's. Those looking to install a desktop on hardware that lacks an
accelerated graphics driver or lower system specifications will have a
useable option.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: N/A
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? No
== Documentation ==
All documentation will be added or updated via the ARM Landing Page.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Anaconda_Reclaim_Disk_Space
== Summary ==
The installer shows the Resize Disk Space dialog to reclaim disk space
for the automatic partitioning in the graphical user interface. The
Anaconda team would like to replace this dialog with a simple list of
predefined choices.
== Owner ==
* Name: [[User:Vponcova| Vendula Poncova]]
* Email: vponcova(a)redhat.com
== Detailed Description ==
The installer shows the Resize Disk Space dialog to reclaim disk space
for the automatic partitioning in the graphical user interface. The
Anaconda team would like to replace this dialog with the following
list of choices:
* Use all disk space
* Use free space available for use
* Replace existing Linux system(s)
* Shrink or remove existing partitions
The first three options will redirect users to the Installation
Summary screen. The automatic partitioning will be configured based on
the selected action.
The last option will redirect users to the Manual Partitioning screen.
Users can shrink or remove existing partitions, automatically create
new partitions and leave the screen.
The Manual Partitioning screen supports all actions of the Resize Disk
Space dialog, so it doesn't make sense to have two user interfaces
with the same functionality.
== Benefit to Fedora ==
Simple predefined choices should improve the user experience for
users, who are not interested in shrinking or removing specific
partitions. Beginners can use all or free disk space without other
interaction. Advanced users can quickly reinstall their systems and
virtual machines.
== Scope ==
* Proposal owners: Implement the new dialog window for the graphical
user interface. The support for the dialog actions is already
implemented for the text user interface and kickstart installations.
It is a very small and isolated change.
* 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 ==
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
During the Fedora installation, it will be easier to set up the
automatic partitioning in the graphical user interface. Users can
choose with one click to use all disk space, all free space or to
replace existing Linux systems.
These options are supported also in the text user interface and
kickstart files, so users might be already familiar with them.
Advanced users can choose to shrink or remove existing partitions.
They will be redirected to the Manual Partitioning screen, where they
can delete and shrink partitions and automatically generate partitions
for the new installation. However, users have much more flexibility at
this point. They can create a fully customized configuration without
having to revisit the Installation Destination screen.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Revert the changes in Anaconda.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis