= Proposed System Wide Change: Mono 4.2 =
https://fedoraproject.org/wiki/Changes/Mono4.2
Change owner(s):
* Claudio Rodrigo Pereyra Diaz <elsupergomez AT fedoraproject DOT org>
Update the Mono stack in Fedora to 4.2 aca Cyle 6
== Detailed Description ==
Mono 4.2 is the last release of Cycle 6 from Xamarin. See more details
at Mono 4.2.1: http://www.mono-project.com/docs/about-mono/releases/4.2.1/
== Scope ==
Proposal owners:
* Mono 4.2 is in rawhide now. Most of the application must work fine
with this update. See [1]
Other developers:
* Need check proper build on alternative platforms like ppc64 and s390
Release engineering: N/A
List of deliverables: N/A
Policies and guidelines: N/A
Trademark approval: N/A
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: LiveUserCreator as Primary Downloadable =
https://fedoraproject.org/wiki/Changes/LUCasPrimaryDownloadable
Change owner(s):
* Jiri Eischmann <eischmann AT redhat DOT com >
* Martin Briza
The new Fedora Liver USB Creator that is being finished has an
overhauled, more user friendly interface. Because USB sticks are the
most common way to install Fedora, it should be the primary download
option. It cover the whole installation media creation, it lets the
user pick the right flavor of Fedora, downloads its image, and copies
it to a USB drive.
== Detailed Description ==
Fedora Live USB Creator is getting a facelift that should make it much
easier to use (see mockups). It should cover the complete work flow of
creating an installation media. It provides information (descriptions,
screenshots,...) about flavors and variants of Fedora to help the user
to pick the right one for their usage, downloads the ISO, and copies
it to a USB flash disk. The goal of this change is to provide this
tool as the primary download option on getfedora.org and create a
mechanism to store and update information (descriptions,
screenshots,...) for the tool. This requires work not only from the
change owners, but also from other groups (websites, design,
marketing, releng teams).
== Scope ==
Proposal owners:
* Live USB Creator for Linux (pretty much ready, currently packaged
for Fedora in Copr, should we create a deb package, too?)
* Live USB Creator for Windows (pretty much ready, we just need to get
a signing key)
* Live USB Creator for Mac OS X (still in progress, should be ready
for F24 release)
Other developers:
* the websites team has to update the download page to make LUC the
primary download option.
Marketing and design:
* the design team has to work with websites team on necessary changes
to the download page.
* the marketing has to provide information for LUC including
descriptions and screenshots (screenshots of Workstation are currently
missing)
QA:
* adjust tests and test result matrices
Release engineering:
* not sure what's required from them
Policies and guidelines:
* The live-usb-creator tool is helping with new installations.
Existing installations are not affected.
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
= Proposed System Wide Change: Langpacks Using RPM Tags =
https://fedoraproject.org/wiki/Changes/LangpacksInstallationWithRPMWeakDepe…
Change owner(s):
* Parag Nemade <pnemade at fedoraproject dot org>
* Jan Silhan <jsilhan at fedoraproject dot org>
Langpacks installations is re-designed using language metapackages
langpacks-<langcode> and RPM weak dependencies (Supplements tag).
== Detailed Description ==
This is similar to what we have dnf langpacks plugin which is already
in Fedora but there is one missing thing that this plugin currently
does not provide automatic installation of langpacks. E.g. if you
enable or install Fedora in Japanese language then installation of any
base package like libreoffice-core or man-pages are not installing
automatically libreoffice-langpack-ja or man-pages-ja. This is because
dnf is not providing required hook to re-resolve the transaction
unlike yum. But now with using RPM tags or weak dependencies like
Supplements, we just need to ensure we have langpacks-xx metapackage
is already installed on the system and when a base package is getting
installed, it will pull its langpack for that xx language
automatically in the transaction set.
This will help in anaconda installation also. When particular set of
languages are selected in anaconda then anaconda should pull all the
required langpacks in the same initial installation.
== Scope ==
Proposal owners:
* Check all langpacks providing packages add Supplements tag in their
each langpack subpackage.
* Create metapackages like langpacks-<langcode>. We have submitted
package review here:
https://bugzilla.redhat.com/show_bug.cgi?id=1300569
Other developers:
* To all other developers of packages who provides langpacks, they
need to add the Supplements tag as given in this draft guideline to
each langpack subpackage.
Release engineering: N/A
Policies and guidelines:
* Working with FPC on this new langpacks guideline:
https://fedoraproject.org/wiki/PackagingDrafts/Langpack
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed Self Contained Change: Erlang 18 =
https://fedoraproject.org/wiki/Changes/Erlang_18
Change owner(s):
* Peter Lemenkov < lemenkov AT gmail DOT com>
* Fedora Erlang SIG <erlang(a)lists.fedoraproject.org>
Update Erlang/OTP to version 18.2.x, and improve Erlang support in Fedora.
== Detailed Description ==
Upgrade Erlang to version 18 which brings a lot of good stuff. Just a
few highlights:
* A lot of scalability and performance improvements.
* Even better Ellyptic Curve Crypto support.
* Initial support for IPv6 Erlang clustering
* New language feature - maps.
* Better, production-ready HiPE support.
Aside from this, we plan to improve quality of Erlang and related
packages. These are shortcomings we want to address:
* We should enable so-called dirty NIF scheduler which is disabled currently.
* Every daemon written in Erlang has its own logging solution which
doesn't use neither syslog nor Journald. We should start switching
them to Journald.
* Erlang packaging is quite complex and mostly undocumented.
* mprove coredump producing and investigating.
== Scope ==
Proposal owners:
* Upgrade Erlang to the latest version (18.2.2). -- Done!
* Fix failures on i686 achitecture.
* We must rebuild every package which requires NIF or Driver version
(listed below in the Dependencies section) against Erlang 18.2.2.
* Every Erlang daemon's systemd unit must require epmd.socket.
* Allow EPMD implementation switching - Erlang is about choice!
* We need to fill new review request for erlang-ejournald
* We have to fill new review request for erlang-lager_journald_backend
* Add another default directory to look for Erlang *.beam files.
* Every Erlang package must require erlang-rpm-macros.
* Upgrade outdated packages:
* Ejabberd
-- We'd better to package all the bundled libraries Ejabberd requires.
* Riak
-- Riak has growing Bugzilla backlog, and badly outdated. We have to
address all of these issues and package some additional libraries
required by new Riak version.
* Wings3D
Other developers: N/A
Release engineering: N/A
Policies and guidelines:
* We should create Erlang Packaging Guidelines which doesn't exist yet.
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed Self Contained Change: QGnomePlatform =
https://fedoraproject.org/wiki/Changes/QGnomePlatform
Change owner(s):
* Jiri Eischmann
* Martin Briza
QGnomePlatform is a Qt Platform Theme aimed to accomodate as much of
GNOME settings as possible and utilize them in Qt applications without
modifying them - making them fit into the environment as well as
possible.
== Detailed Description ==
The goal of this project is to make KDE/Qt applications as seamlessly
integrated in GNOME (and thus Fedora Workstation) as possible by
synchronizing KDE/Qt settings with GNOME/GTK settings. We already have
the Adwaita theme ported to Qt, but the way themes are set in Qt has
changed with the version 5, so currently only Qt4 apps pick up the
Adwaita theme in Fedora Workstation. QGnomePlatform should solve it
for Qt5 apps, too. But the scope of the project is larger, it should
also cover other UI settings. For Fedora 24, we're planning to cover
the theme, font settings, window scaling on HiDPI monitors. In the
future, we'd like to cover more things such as font scaling.
See the upstream project page: https://github.com/MartinBriza/QGnomePlatform
== Scope ==
Proposal owners:
* will have to implement all the promised features, package it, and
have it included in Fedora Workstation.
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
= Proposed Self Contained Change: Ping IPv6 =
https://fedoraproject.org/wiki/Changes/PingIpv6#Ping_IPv6
Change owner(s):
* Jan Synacek, Nikos Mavrogiannopoulos <nmav AT redhat DOT com>
ping should be able to work with IPv6 and IPv4 addresses, eliminating
the need for multiple tools.
== Detailed Description ==
The current system of using different software (ping vs ping6) for
different versions of the IP stack is broken. As the IPv6 transition
moves ahead its unreasonable to expect users to know in advance the IP
version of a peer referenced using a DNS name, nor expect them to
switch tools based on the types of IPs they are testing.
ping must work with both protocol versions by default.
== Scope ==
Proposal owners:
* The ping tool should be able to test any address provided on command
line, being IPv6 or IPv4. That means that the ping tool from iputils
as we include it in Fedora needs to be modified.
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
= Proposed Self Contained Change: Atomic Developer Mode =
https://fedoraproject.org/wiki/Changes/Atomic_Developer_Mode
Change owner(s):
* Jonathan Lebon < jlebon AT redhat DOT com>
Add a "Developer Mode" boot menu entry in the Atomic image to allow
users to boot without setting up cloud-init.
== Detailed Description ==
The high-level goal of Atomic Developer Mode is to make the Fedora
Atomic Host image more accessible by providing a new GRUB 2 menu item
labeled e.g. "Fedora 24 (Twenty Four) Developer Mode". This mode is an
attempt to provide a painless experience for folks who want to try out
Atomic but (1) do not want to bother setting up a cloud-init
datasource, or (2) do not know anything about cloud-init, or even (3)
do not have much experience with Linux overall. They just want to try
out e.g. /usr/bin/atomic, /usr/bin/docker, or play with the Cockpit
console.
Since the functionality is completely integrated into the image, there
are no requirements on the host system, other than its ability to boot
VMs. When booted in Developer Mode, the following happens:
* cloud-init uses a local built-in datasource
* a new root password is generated
* the root user is automatically logged in on tty1
* the cockpit/ws image is downloaded and started
* a tmux session is started on tty1 to provide all the relevant
information (root password, IP address, Cockpit console address)
More information and discussion can be found on the Cloud SIG mailing list
== Scope ==
Proposal owners:
* Create an atomic-devmode package to hold the helper files needed for
this feature -- DONE
* Add the atomic-devmode package to the Fedora repos
* Submit the necessary changes to repos related with tree and image creation:
1. Submit a patch to fedora-atomic to have the atomic-devmode
package part of the default tree compose
2. Submit a patch to spin-kickstarts to have the boot menu item
added in the kickstart %post
* Work with projectatomic.io maintainers to properly present Atomic
Developer Mode (including updating the Quick Start Guide)
Other developers: N/A (not a System Wide Change)
Release engineering: 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
= Proposed Self Contained Change: Atomic Storage Clients =
https://fedoraproject.org/wiki/Changes/AtomicStorageClients
Change owner(s):
* mmicene <nzwulfin AT gmail DOT com >
Kubernetes provides a mechanism for providing storage to Pods via
volumes. Volumes support several underlying storage protocols, but
clients are needed to support each type. Native GlusterFS and Ceph
clients will be added to the Atomic host base to support these Volume
types.
== Detailed Description ==
By design, Docker container internal storage is ephemeral in nature
and data is lost when a container is stopped. Kubernetes uses Volumes
to provide a means for Pods keep data for extended periods of time and
between container restarts.
A Volume in Kubernetes represents a real piece of underlying storage
capacity in the infrastructure. Persistent Volumes are a way for users
to "claim" a Volume without knowing the details of the particular
storage environment. Persistent volumes are intended for "network
volumes" like NFS shares, iSCSI devices, GlusterFS volumes, or Ceph
devices. Persistent Volumes also exist past the Pod lifecycle.
In order to access the underlying storage, the appropriate drivers
must be available to Kubernetes on the Atomic host. We will add the
appropriate packages to support the following Volume types:
* GlusterFS
* RBD (Ceph Block Device)
Both projects currently have packages available and accepted in Fedora
for general use. No new packaging should be required.
== Scope ==
Proposal owners:
* Add GlusterFS client Fedora packages to Atomic package list
* Add Ceph client Fedora packages to Atomic package list
-- The Ceph packaging will be changing to reduce the number of
dependencies. This may cause some bloat in the image until fixed.
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
At the FESCo meeting on October 14th [1], it was decided that the time
has come to finally complete the migration away from System V init
scripts.
This email is a reminder about this Change, following the announcement
sent by Stephen Gallagher [2].
You might also want to check the list of possibly affected packages [2].
The branch of F24 from rawhide is currently scheduled on 2016-02-23.
As previously announced, any package that has not been migrated from
System V init scripts to systemd units before this date will be
retired from the Fedora package collection. Exceptions to this must be
requested by FESCo ticket no later than February 2nd.
[1] https://meetbot.fedoraproject.org/teams/fesco/fesco.2015-10-14-18.01.html
[2] bit.ly/1ZBEqhc
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Hello, Fedora people,
Earlier this month, it was brought to FESCo's attention that when it
had made the initial Fedora 24 schedule, it failed to accommodate a
necessary mass-rebuild for the GCC 6 compiler. As a result, FESCo
decided[2] to slip the release by at least two weeks and by as much as
three weeks, pending feedback by the GCC team.
After that feedback was received, it became clear that the full three
weeks slip would be needed, so we are extending the slip of Fedora 24
by one additional week from the previous announcement.
For full details, see the updated schedule[3].
Dates for the most important milestones:
2016-03-22 Alpha Release
2015-05-03 Beta Release
2016-06-07 Fedora 24 Final Release (GA)
[1] https://lists.fedoraproject.org/archives/list/devel-announce%40lists.fedora…
[2] https://meetbot.fedoraproject.org/teams/fesco/fesco.2016-01-08-17.22.html
[3] https://fedoraproject.org/wiki/Releases/24/Schedule#Key_Milestones
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic