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
https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
= Switch RPMs to zstd compression =
== Summary ==
Binary RPMs are currently compressed with xz level 2.
Switching to zstd would increase decompression speed significantly.
== Owner ==
* Name: [[User:dmach| Daniel Mach]]
* Email: dmach(a)redhat.com
== Detailed Description ==
* The change requires setting a new compression algorithm in rpm
macros. Then a mass rebuild of all packages is required.
* The macro for setting the compression is: %define _binary_payload w19.zstdio
* The recommended compression level is 19. The builds will take
longer, but the additional compression time is negligible in the total
build time and it pays off in better compression ratio than xz lvl2
has.
* SRPM payload compression should stay at gzip (there's almost no
benefit in changing the compression, because SRPM's contents is
compressed already)
=== Use case: Firefox installation ===
I rebuilt firefox-66.0.5-1.fc30 with zstd level19.
Then I compared installation times with the original (xz compressed) package:
{| class="wikitable"
|-
! Compression !! Target File System !! Time
|-
| xz level 2 || tmpfs || 8s
|-
| xz level 2 || ext4 on nvme || 11s
|-
| zstd level 19 || tmpfs || 2s
|-
| zstd level 19 || ext4 on nvme || 4s
|-
|}
=== Comparison of compression algorithms and levels ===
Following table shows '''cpio''' and '''compressed cpio''' extraction
times into a tmpfs. Actual times in decompressing RPMs will differ due
to extracting on an actual disk and also some overhead in the RPM tool
(checks, scriptlets).
{| class="wikitable"
|-
! Compression !! Level !! Size B !! Size GiB
!! Compression time !! Compression time, 4 threads !!
Decompression time !! Comment
|-
| CPIO || - || 5016785692 || 4,7
|| - || - || -
||
|-
| xz || 2 || 1615017616 || 1,6
|| 9m55s || - || 1m36s
|| slow decompression
|-
| pxz || 2 || 1631869880 || 1,6
|| - || 6m11s || 1m38s
|| slow decompression
|-
| gzip || 9 || 2086354992 || 2,0
|| 10m23s || - || 31s
|| insufficient compression ratio
|-
| bzip2 || 9 || 1889161565 || 1,8
|| 8m || - || 2m50s
|| very slow decompression; compression ratio could be
better
|-
| zstd || 3 || 1913536587 || 1,8
|| 31s || 29s || 6,5s
||
|-
| zstd || 10 || 1737928978 || 1,7
|| 3m27s || 2m34s || 6,3s
||
|-
| zstd || 15 || 1717303256 || 1,7
|| 9m37s || 6m34s || 6,3s
|| identical compression speed to xz; fast decompression;
slightly worse compression ratio than xz
|-
| zstd || 17 || 1635525492 || 1,6
|| 16m16s || 11m20s || 6,7s
||
|-
| zstd || 19 || 1575843696 || 1,5
|| 24m2s || 18m55s || 7,7s
||
|-
|}
== Benefit to Fedora ==
* Faster installations/upgrades of user systems
* Faster koji builds (installations in build roots)
* Faster container builds
* Lower bandwidth on mirrors if we choose the highest compression level
== Scope ==
* Proposal owners: submit a patch to redhat-rpm-config
* Other developers: redhat-rpm-config maintainer: include the patch
and make a new build
* Release engineering: [https://pagure.io/releng/issue/8345 #8345]
mass rebuild is needed
== Upgrade/compatibility impact ==
* RPM in Fedora supports zstd compression already (from Fedora 28,
rpm-4.14.0-0.rc2.5.fc28). No impact on Fedora users is expected.
* Fedora <= 27 and some other distros will not be able to decompress
zstd-compressed RPMs.
== How To Test ==
* dnf install <package>
* rpm -q --qf "%{PAYLOADCOMPRESSOR} %{PAYLOADFLAGS}\n" <package>
* expected output: zstd 19
Also the overall system installation time should decrease significantly.
== User Experience ==
See '''Benefit to Fedora'''
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Not needed, Fedora will stay at current compression.
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? N/A
== Documentation ==
N/A
== Release Notes ==
RPMs have switched to zstd compression level 19.
Users will benefit from faster package decompression.
Users that build their packages will experience slightly longer build times.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
As of the 28th of May 2019, Fedora 28 has reached its end of life
for updates and support. No further updates, including security
updates, will be available for Fedora 28. Fedora 29 will continue to receive
updates until approximately one month after the release of Fedora 31.
The maintenance schedule of Fedora releases is documented on the
Fedora Project wiki [0]. The Fedora Project wiki also contains
instructions [1] on how to upgrade from a previous release of Fedora
to a version receiving updates.
Regards,
Mohan Boddu.
[0]
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedu…
[1]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades
https://fedoraproject.org/wiki/Changes/Nodejs12x
== Summary ==
The latest release of Node.js to carry a 30-month lifecycle is the
12.x series. As with 10.x and 8.x before it, Fedora 31 will carry 12.x
as the default Node.js interpreter for the system. The 10.x
interpreter will remain available as a non-default module stream.
== Owner ==
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgallagh(a)fedoraproject.org
* Responsible SIG: Node.js SIG
== Detailed Description ==
Fedora 31 will ship with the latest LTS version of Node.js by default.
This will either be the `nodejs:12` module stream or else replicated
to the non-modular repository, depending on the status of other
release engineering work around supporting modular content in the
non-modular buildroots. To end-users, the experience should be
identical: `dnf install nodejs` will give them `nodejs-12.x` and the
matching `npm` package.
== Benefit to Fedora ==
Node.js is a popular server-side JavaScript engine. Keeping Fedora on
the latest release allows us to continue tracking the state-of-the-art
in that space. For those whose applications do not yet work with the
12.x release, Fedora 31 will also have the 10.x release available as a
selectable module stream.
== Scope ==
* Proposal owners:
The packages are already built for Fedora 31 in a non-default module
stream. On June 14th, 2019, the nodejs-12.x packages will become the
default in Fedora 31 (either by making the 12.x module stream be the
default stream or by rebuilding the packages as non-modular ,
depending on other factors).
If the non-modular buildroot work is finished and available by July
17th (a week before the mass-rebuild), Node.js 12.x will drop the
non-modular packages and make the 12.x stream the default.
* Other developers:
Any developer with a package that depends on Node.js at run-time or
build-time should test with the 12.x module stream enabled as soon as
possible. Issues should be reported to nodejs(a)lists.fedoraproject.org
* Release engineering: [https://pagure.io/releng/issue/8388 #8388]
Release engineering and FESCo will need to approve the change to the
default module stream.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
As with previous releases, users running Fedora 29 or Fedora 30 with
the non-modular nodejs-10.x packages will be automatically upgraded to
the 12.x packages, which may cause issues. If users are running
software known not to support Node.js 12.x yet, they can switch the
system back to using 10.x with yum commands (to be documented in
release notes).
== How To Test ==
* Confirm that `yum install nodejs` results in Node.js 12.x being installed.
* Confirm that upgrading from Fedora 29 or Fedora 30 with nodejs-10.x
installed (non-modular) results in an upgrade to nodejs-12.x
* Confirm that upgrading from Fedora 29 or Fedora 30 with the
`nodejs:10` module enabled does *not* result in an upgrade to 12.x and
still has `nodejs:10` enabled on Fedora 31.
* Confirm that upgrading from Fedora 29 or Fedora 30 with the
`nodejs:12` module enabled upgrades successfully and still has
`nodejs:12` enabled on Fedora 31.
== User Experience ==
Users will have the 12.x release of Node.js available by default. See
the "Upgrade/compatibility impact" section for specific details.
== Dependencies ==
All packages prefixed with `nodejs-` depend on this package. They will
need to be updated or removed from Fedora 31 if they do not work with
Node.js 12.x.
== Contingency Plan ==
* Contingency mechanism:
Revert to Node.js 10.x as the default stream. This may require bumping
epoch or making the `nodejs:10` stream the default, depending on the
status of the modules-in-non-modular-buildroot work at the time.
* Contingency deadline: August 5th, 2019
* Blocks release? No
== Documentation ==
* https://nodejs.org/dist/latest-v12.x/docs/api/
* https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V12.md
== Release Notes ==
Fedora 31 now ships with Node.js 12.x as the default Node.js
JavaScript server-side engine. If your applications are not yet ready
for this newer version, you can revert to the 10.x series by running
the following commands
<pre>
dnf remove nodejs
dnf module reset nodejs
dnf module install nodejs:10
</pre>
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/RPM-4.15
== Summary ==
Update RPM to the 4.15.0 release.
== Owner ==
* Name: User:pmatilai, User:ffesti
* Email: pmatilai@redhat.com,ffesti@redhat.com
== Detailed Description ==
RPM 4.15 contains numerous improvements over previous versions
* Faster builds due to increased parallelism
* Dynamic build dependency generator (planned)
* Caret version operator (the opposite of tilde)
* String data is returned as surrogate-escaped utf-8 in Python 3 bindings
* %patchlist and %sourcelist spec sections for minimal boilerplate
patch and source declarations
* Experimental chroot operations for non-root users
* Many error and warning report improvements
* A new plugin for issuing audit log events on package install/update/erase
* Native support for Lua 5.2-5.3 without compat defines in Lua
* Numerous other improvements and bugfixes: https://rpm.org/wiki/Releases/4.15.0
Rawhide rpm will be updated to 4.15 alpha once released and updated through
beta and rc cycles, 5.15.0 final release is expected prior to F31 final freeze.
== Benefit to Fedora ==
See above.
== Scope ==
* Proposal owners:
** Rebase RPM
** help Python binding users adjust to the string change
** help coordinate for macro + helper script removals
* Other developers:
** Test new release, report issues and bugs.
** Fix Python 3 string/bytes usages in API users
(https://bugzilla.redhat.com/show_bug.cgi?id=1693751 already in
progress in rawhide)
* Release engineering: [https://pagure.io/releng/issue/8380 #8380]
* Policies and guidelines:
As always, utilizing new rpm features is subject to packaging guidelines,
but the time for this is after the new version has properly landed.
There is no need to change guidelines, any new features are optional.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
* Python 3 bindings see a dramatic change as all string data is now
returned as utf-8 encoded string instead of bytes, but this is already
being test-driven in rawhide and at least anaconda, dnf and mock are
already compatible:
https://bugzilla.redhat.com/show_bug.cgi?id=1631292
* Similar to compiler updates, some previously working specs might
fail to build due to stricter error checking and the like.
* Some long-standing perl and python macros and helpers have been
removed from rpm and might need either changes to packages or
redhat-rpm-config
== How To Test ==
Rpm receives a thorough and constant testing via every single package
build, system installs and updates. New features can be tested
specifically as per their documentation.
== User Experience ==
There are no significant user experience changes, but some more minor
ones include:
* faster package builds on SMP systems
* improved diagnostics from macro errors/warnings and spec constrcuts
== Dependencies ==
* There is a soname bump involved so all API-dependent packages will
need a rebuild.
* The Python 3 string change has impact on several packages but this
is already in process
== Contingency Plan ==
* Contingency mechanism: Roll back to rpm 4.14, but under no
circumstances should such a thing be necessary.
* Contingency deadline: Beta freeze.
* Blocks release? No
== Documentation ==
Draft release notes available at https://rpm.org/wiki/Releases/4.15.0
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
There will be an outage starting at 2019-05-22 21:00 UTC ,
which will last approximately 5 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2019-05-22 21:00UTC'
Reason for outage:
There have been a number of kernel and low level library updates which
require a system reboot to put into place. We will be rebooting
productions servers which do require a full outage and downtime.
Affected Services:
koji.fedoraproject.orgsrc.fedoraproject.org
*.phx2.fedoraproject.org
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/7810
Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.
--
Stephen J Smoogen.
There will be an outage starting at 2019-05-21 21: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-05-21 21:00UTC'
Reason for outage:
We have come to chew gum and reboot servers, and we have all run out of gum.
There have been a number of kernel and low level library updates which
require a system reboot to put into place. We will be rebooting staging and
non-PHX2 servers which do not require a full outage due to redundancy or
low service level expectations.
Affected Services:
proxy05.fedoraproject.org
coloamer01.fedoraproject.org:proxy08.fedoraproject.org:running:1
dedicatedsolutions01.fedoraproject.org:proxy11.fedoraproject.org:running:1
ibiblio01.fedoraproject.org:download-ib01.fedoraproject.org:running:1
ibiblio01.fedoraproject.org:noc02.fedoraproject.org:running:1
ibiblio01.fedoraproject.org:pagure-proxy01.fedoraproject.org:running:1
ibiblio01.fedoraproject.org:proxy04.fedoraproject.org:running:1
ibiblio05.fedoraproject.org:ns02.fedoraproject.org:running:1
ibiblio05.fedoraproject.org:people02.fedoraproject.org:running:1
ibiblio05.fedoraproject.org:proxy12.fedoraproject.org:running:1
ibiblio05.fedoraproject.org:smtp-mm-ib01.fedoraproject.org:running:1
ibiblio05.fedoraproject.org:torrent02.fedoraproject.org:running:1
ibiblio05.fedoraproject.org:unbound-ib01.fedoraproject.org:running:1
internetx01.fedoraproject.org:ns05.fedoraproject.org:running:1
internetx01.fedoraproject.org:proxy02.fedoraproject.org:running:1
osuosl01.fedoraproject.org:pagure01.fedoraproject.org:running:1
osuosl01.fedoraproject.org:proxy06.fedoraproject.org:running:1
osuosl01.fedoraproject.org:repospanner-osuosl01.fedoraproject.org:running:1
osuosl02.fedoraproject.org:keys01.fedoraproject.org:running:1
osuosl02.fedoraproject.org:pagure-stg01.fedoraproject.org:running:1
osuosl02.fedoraproject.org:proxy09.fedoraproject.org:running:1
osuosl02.fedoraproject.org:smtp-mm-osuosl01.fedoraproject.org:running:1
osuosl02.fedoraproject.org:unbound-osuosl01.fedoraproject.org:running:1
virthost-cc-rdu01.fedoraproject.org:ci-cc-rdu01.fedoraproject.org:running:1
virthost-cc-rdu01.fedoraproject.org:proxy14.fedoraproject.org:running:1
virthost-cc-rdu01.fedoraproject.org:smtp-mm-cc-rdu01.fedoraproject.org:running:1
virthost-cc-rdu02.fedoraproject.org:infinote.fedoraproject.org:running:1
virthost-cc-rdu02.fedoraproject.org:proxy03.fedoraproject.org:running:1
virthost-cc-rdu02.fedoraproject.org:repospanner-cc-rdu01.fedoraproject.org:running:1
virthost-cc-rdu02.fedoraproject.org:unbound-cc-rdu01.fedoraproject.org:running:1
virthost-cc-rdu03.fedoraproject.org:download-cc-rdu01.fedoraproject.org:running:1
virthost-cc-rdu03.fedoraproject.org:ipv6-test.fedoraproject.org:running:1
virthost-rdu01.fedoraproject.org:bastion13.fedoraproject.org:running:1
virthost-rdu01.fedoraproject.org:batcave13.rdu2.fedoraproject.org:running:1
virthost-rdu01.fedoraproject.org:ns13.rdu2.fedoraproject.org:running:1
virthost-rdu01.fedoraproject.org:proxy13.fedoraproject.org:running:1
data-analysis01.phx2.fedoraproject.orgdl.fedoraproject.org (service has multiple front ends so outages should be
short per)
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/7809
Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.
--
Stephen J Smoogen.