F24 Self Contained Change: Shenandoah 1.0
by Jan Kurik
= Proposed Self Contained Change: Shenandoah 1.0 =
https://fedoraproject.org/wiki/Changes/Shenandoah
Change owner(s):
* Christine H. Flood <chf AT redhat DOT com>
* Roman Kennke <rkennke AT redhat DOT com>
This change aims at adding a very low pause time Garbage
Collection(GC) algorithm named Shenandoah to OpenJDK.
== Detailed Description ==
We have implemented a new GC algorithm called Shenandoah in OpenJDK.
This GC does more of the GC work while the Java threads are running so
we can do less work during the stop the world pause and therefore
minimize the amount of time the Java threads are stopped. This is
targeted at high availability Java applications with large heaps which
are concerned with responsiveness.
== Scope ==
Proposal owners:
* The work is an official OpenJDK project but the OpenJDK committee
have not committed to including it upstream. Including Shenandoah in
Fedora will give us a chance to get early user feedback.
* This is an isolated change activated by a -XX:+UseShenandoahGC flag.
Users who don't choose to activate the change will see no differences.
Users who do activate the flag should see lower pause times on large
heaps.
* We have made some small changes to the Java compiler and Java
runtime system to add read barriers and more extensive write barriers.
The bulk of our changes have been in an isolated directory. All of the
changes are only activated if the -XX:+UseShenandoahGC flag is set.
Other developers: N/A
Release engineering: N/A
Policies and guidelines: N/A
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
8 years, 1 month
F24 System Wide Change: The GNU C Library version 2.23
by Jan Kurik
= Proposed System Wide Change: The GNU C Library version 2.23 =
https://fedoraproject.org/wiki/Changes/GLIBC223
Change owner(s):
* Carlos O'Donell <carlos AT redhat DOT com>
Switch glibc in Fedora 24 to glibc version 2.23.
== Detailed Description ==
The GNU C Library version 2.23 will be released at the end of February
2016; we have started closely tracking the glibc 2.23 development code
in Fedora Rawhide and are addressing any issues as they arise. Given
the present schedule Fedora 24 will branch before GLIBC 2.23. Fedora
24 will be rebased on the stable GLIBC 2.23 release.
== Scope ==
Proposal owners:
* Update glibc to 2.23 from tested upstream release.
Other developers:
* Aside from Carlos O'Donell <carlos AT redhat DOT com>, Florian
Weimer <fweimer AT redhat DOT com>, Torvald Riegel <triegel AT redhat
DOT com>, Martin Sebor <msebor AT redhat DOT com>, and Patsy Franklin
<pfrankli AT redhat DOT com>, no other developers are required. These
developers need to ensure that rawhide is stable and ready for the
Fedora 24 branch. Given that glibc is backwards compatible and we have
been testing the new glibc in rawhide it should make very little
impact when updated.
Release engineering:
* In general coordination with release engineering is not required. A
mass rebuild is not required.
Policies and guidelines:
* The policies and guidelines do not need to be updated.
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
8 years, 1 month
F24 System Wide Change: Removal of librtkaio from glibc
by Jan Kurik
= Proposed System Wide Change: Removal of librtkaio from glibc =
https://fedoraproject.org/wiki/Changes/GLIBC223_librtkaio_removal
Change owner(s):
* Carlos O'Donell <carlos AT redhat DOT com>
Remove librtkaio support from glibc in Fedora 24.
== Detailed Description ==
On July 2003 the rtkaio add-on was added to Fedora in glibc 2.3.2-64.
The rtkaio add-on provided a POSIX realtime API interface that used
linux kernel Asynchronous IO support (KAIO) to provide high
performance AIO for a small subset of files (those using O_DIRECT, and
not all file types). Typically the use case was databases or
high-speed transactional systems that needed fast AIO. The libraries
were installed under /lib64/rtkaio/ e.g. /lib64/rtkaio/librt.so.1
(symlink to /lib64/rtkaio/librtkaio-X.Y.so with SONAME librt.so.1) and
could be used by preloading (LD_PRELOAD), dynamic linker lookup path
changes (LD_LIBRARY_PATH) or by directly opening the shared library
(dlopen). This accelerated access to file was used by customers like
Sybase during the development of their database Sybase ASE (now owned
by SAP).
It has been 12 years since rtkaio was released, and while it has seen
some uptake, the only known usage example is Sybase ASE. Sybase now
exclusively uses the Linux Kernel Asynchronous I/O Library (libaio)
for over 10 years ago and no longer use rtkaio. The libaio project
provides a unique API that is tailored to doing very fast AIO. An
analysis of Fedora shows no packages using rtkaio. Lastly the rtkaio
add-on was never contributed upstream, likely because it never
provided full POSIX conformance and worked only with a small subset of
the required POSIX realtime features, those supported by KAIO.
It is the conclusion of the Fedora glibc team that the maintenance
burden of rtkaio is no longer warranted. The glibc team suggest rtkaio
be deprecated and removed. Application developers should use libaio if
they want high performance KAIO, or use librt if they want portable
and flexible AIO.
What are the consequences of removing rtkaio?
* Application developers using rtkaio will see a performance decrease
if they were previously using KAIO on O_DIRECT opened files, but
should otherwise see no semantic changes in their applications.
* Application developers using LD_PRELOAD will see a warning that the
preloaded library is missing, but the application will load the normal
librt and continue to operate correctly.
* Application developers using LD_LIBRARY_PATH will see no warning,
and the application will load the normal librt and continue to operate
correctly.
* Application developers using dlopen will see a failure from dlopen
since the library is missing. This is mitigated by shipping a symlink
from the rtkaio library to librt in the official Fedora release.
The rtkaio library and the librt library are ABI and API compatible,
and therefore interchangeable. As long as we provide one of them we
will meet our application compatibility requirements. We will continue
to provide the POSIX realtime library (librt) forever.
The following plan of action is suggested:
* Immediately remove rtkaio from Fedora Rawhide, deprecating the library.
See https://bugzilla.redhat.com/show_bug.cgi?id=1227855
No compatibility symlinks are provided for Rawhide. We want to use
Rawhide to detect if any applications are actually using rtkaio.
Before the F24 branch a compatibility symlink will be added and left
in place for a full release after which it will be removed.
== Scope ==
Proposal owners:
* Update glibc and remove librtkaio.
Other developers:
* Aside from Carlos O'Donell <carlos AT redhat DOT com>, Siddhesh
Poyarekar <siddhesh AT redhat DOT com>, Torvald Riegel <triegel AT
redhat DOT com>, Martin Sebor <msebor AT redhat DOT com>, and Patsy
Franklin <pfrankli AT redhat DOT com>, no other developers are
required. These developers need to ensure that rawhide is stable and
ready for the Fedora 24 branch. Given that glibc is backwards
compatible and we have been testing the new glibc in rawhide it should
make very little impact when librtkaio is removed.
Release engineering: In general coordination with release engineering
is not required. A mass rebuild is not required.
Policies and guidelines: The policies and guidelines do not need to be updated.
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
8 years, 1 month
F24 System Wide Change: GNOME 3.20
by Jan Kurik
= Proposed System Wide Change: GNOME 3.20 =
https://fedoraproject.org/wiki/Changes/GNOME3.20
Change owner(s):
* Kalev Lember <klember AT redhat DOT com>
Update GNOME to the latest upstream release, 3.20
== Detailed Description ==
The new features for 3.20 include:
* Graphical System Upgrades
* Cantarell font improvements
* Shortcuts windows
* New Mouse and Touchpad Settings
* Improved CSS theming for GTK+ apps
== Scope ==
Proposal owners:
* Keep existing GNOME packages updated
* Follow upstream module changes
* Package new applications and new dependencies of existing GNOME
packages for GNOME 3.20
Other developers: N/A
Release engineering: N/A
Policies and guidelines: N/A
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
8 years, 1 month
F24 Self Contained Change: Graphical System Upgrades
by Jan Kurik
= Proposed Self Contained Change: Graphical System Upgrades =
https://fedoraproject.org/wiki/Changes/GraphicalSystemUpgrades
Change owner(s):
* Kalev Lember < klember AT redhat DOT com >
Add support for performing system upgrades to a newer Fedora release
through GNOME Software.
== Detailed Description ==
We'll implement a graphical user interface for system upgrades. The
implementation will use PackageKit and the libhif stack as a backend
and GNOME Software as a frontend. First supported version is going to
be Fedora 23->24 upgrades.
== Scope ==
Proposal owners:
* Implement this change
Other developers: N/A (not a System Wide Change)
Release engineering: N/A (not a System Wide Change)
List of deliverables: 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)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
8 years, 1 month
Fedora 24 Bugzilla Rawhide rebase
by Jan Kurik
Greetings,
This e-mail is intended to inform you about the upcoming Bugzilla changes
happening on 2016-Feb-23 (Rawhide bug rebase) and what you need to do,
if anything.
We will be automatically changing the version for most rawhide bugs to
Fedora 24.
This will result in regular bugs reported against rawhide during the Fedora 24
development cycle being changed to version ‘24' instead of their current
assignment, ‘rawhide’. This is to align with the branching of Fedora 24 from
rawhide and to more accurately tell where in the lineage of releases the bug was
last reported.
Note that this procedure does not apply to bugs that are open for the "Package
Review" component or bugs that have the ''FutureFeature'' or
''Tracking'' keywords
set. These will stay open as rawhide bugs indefinitely.
If you do not want your bugs changed to version ‘24‘, add the ''FutureFeature''
keyword. If you need help changing a large amount of bugs manually, we’d be glad
to help.
The process was re-approved by FESCo https://fedorahosted.org/fesco/ticket/1096.
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
8 years, 1 month