Proposed F19 Feature: New firstboot
by Jaroslav Reznik
= Features/NewFirstboot =
https://fedoraproject.org/wiki/Features/NewFirstboot
Feature owner(s): Martin Sivák <msivak(a)redhat.com>
This feature proposes new initial setup application with better integration to
the NewUI anaconda and to Gnome Initial Experience.
== Detailed description ==
Since the Anaconda installer moved to the NewUI Hub and Spoke concept, we can
reuse much of it's architecture and screens in the after reboot configuration
utility -- initial-setup. So the idea behind the firstboot replacement is that
we will have a new app that will use the same Hub and Spoke model and the same
API as Anaconda.
This will give us the possibility of letting the user configure his system
either during the package extraction or after reboot (important for OEMs). It
will also allow other teams (power management, security team, IPA) to prepare
their own screens for Anaconda and initial-setup and so further enhancing the
user experience.
Anaconda, initial-setup and Gnome Inital Experience will communicate to ensure
the screens are not shown multiple times. So for example the root password
setup or user creation process will be done only in one place, depending on
the installed system.
The old Firstboot will still stay as a fallback in case somebody still has his
old Firstboot plugins he needs to use.
11 years, 2 months
Proposed F19 Feature: MinGW GCC 4.8
by Jaroslav Reznik
= Features/MinGW GCC 4.8 =
https://fedoraproject.org/wiki/Features/MinGW_GCC_4.8
Feature owner(s): Erik van Pienbroek <epienbro(a)fedoraproject.org>
Update the mingw-gcc cross-compiler to gcc 4.8 and rebuild all MinGW packages
against it.
== Detailed description ==
The Fedora MinGW SIG maintains over a large number of packages which allows
users to build binaries for the win32 and win64 targets using the mingw-w64
toolchain. One of the goals of the Fedora MinGW SIG is to have the package
versions as close as possible to their native counterparts as mentioned in our
packaging guidelines.
As gcc 4.8 was accepted as a feature for Fedora 19 we intend to update the
mingw-gcc package in Fedora 19 as well to gcc 4.8.
11 years, 2 months
Proposed F19 Feature: libkkc - a new Japanese Kana Kanji input library
by Jaroslav Reznik
= Features/libkkc =
https://fedoraproject.org/wiki/Features/libkkc
Feature owner(s): Daiki Ueno <ueno at gnu.org>
libkkc, a new Japanese Kana Kanji input library, will be available in Fedora
19, along with an IBus input method engine which uses libkkc as backend (ibus-
kkc).
== Detailed description ==
There are currently two options for typical users to input Japanese sentences:
ibus-anthy or ibus-mozc. However, both have issues:
* ibus-anthy
- Anthy, the backend library, has been dead upstream for years.
- The accuracy is not good because of bugs in the core algorithm of Anthy.
* ibus-mozc
- Contributions to the input method are limited to Google employees.
- There are no library interface. That means it cannot easily be used by other
input method frameworks than IBus, such as Fcitx and uim.
libkkc and ibus-kkc will be a better replacement of those.
11 years, 2 months
Proposed F19 Feature: Developers Assistant
by Jaroslav Reznik
= Features/DevelopersAssistant =
https://fedoraproject.org/wiki/Features/DevelopersAssistant
Feature owner(s): Jan Zelený <jzeleny(a)redhat.com>, Marcela Mašláňová
<mmaslano(a)redhat.com>
Perform a series of various changes to improve developer experience on Fedora.
== Detailed description ==
This feature aims on setting up development environment for various languages.
Target groups include beginning developers but also experienced developers not
used to GNU/Linux as well as experienced Linux developers not used to Fedora.
This feature will cover a basic set of tasks which will prepare Fedora for
later additions. The first part of the feature is a review of comps groups
which would lead to better granularity of package sets necessary for
development in different languages. Another part is about providing tool or
tools for simple start of a project in terms of creating project template
based on different languages and/or frameworks which the project should use.
There are other optional activities like vim/eclipse/emacs/... plugins,
integration of rpm build tools, .... These optional parts are not goal for F19
but they will be integrated in time.
Languages:
C (phracek)
Ruby (vondruch)
Python (bkabrda)
Perl (mmaslano)
PHP (rcollet)
Java (msrb)
Javascript
11 years, 2 months
Proposed F19 Feature: GSS Proxy
by Jaroslav Reznik
= Features/gss-proxy =
https://fedoraproject.org/wiki/Features/gss-proxy
Feature owner(s): Simo Sorce <ssorce(a)redhat.com>, Günther Deschner
<gdeschner(a)redhat.com>
The main purpose of this project is to replace rpc.svcgssd(8), the server-side
rpcsec_gss daemon.
The gss-proxy consists of a standardized RPC protocol, a client and server
implementation with other future components. The gss-proxy protocol allows
proxying of GSSAPI initiation and authentication.
== Detailed description ==
The goal is to have a GSS-API proxy, with standardizable protocol and a
[somewhat portable] reference client and server implementation. There are
several motivations for this some of which are:
- Kernel-mode GSS-API applications (CIFS, NFS, AFS, ...) need to be
able to leave all complexity of GSS_Init/Accept_sec_context() out of
the kernel by upcalling to a daemon that does all the dirty work.
- Isolation and privilege separation for user-mode applications. For
example: letting HTTP servers use but not see the keytab entries for
HTTP/* principals for accepting security contexts.
- Possibly an ssh-agent-like SSH agent for GSS credentials -- a
gss-agent.
In order to use the gssproxy only the gssproxy daemon has to be started at
boottime. Once this is done, the GSSAPI mechglue library will make sure all
GSSAPI calls issued by an application are directed to the gssproxy service
transparently. Depending on the configuration of the system, the gssproxy
daemon will then allow or disallow access to cryptographic keys stored in
keytabs on the system.
Two major features that are planned to be achieved for Fedora19:
- rpc.gssd, the NFS client application, should be enabled to use the gssproxy.
It will be possible to aquire tickets for kerberized NFS mounts given user
keytabs.
- gssproxy will offer Kerberos ticket renewal when user keytabs are available
11 years, 2 months
Proposed F19 Feature: Performance Co-Pilot Feature Update
by Jaroslav Reznik
= Features/Pcp4 =
https://fedoraproject.org/wiki/Features/Pcp4
Feature owner(s): Frank Ch. Eigler <fche(a)redhat.com>, Mark Goodwin
<mgoodwin(a)redhat.com>, Nathan Scott <nathans(a)redhat.com>
A new feature release of PCP (Performance Co-Pilot).
== Detailed description ==
This PCP update is planned to deliver a group of new features:
Increased security (SSL transport, authenticated/authorized remote access)
IPv6 support
JSON interface for web monitoring clients
RRD format data interoperation
Improved user interfaces (pmchart, possible web gui)
Improvements to Python scripting
Instrumentation and monitoring for systemd and GFS2 clusters
11 years, 2 months
Fedora 19 Feature Submission Deadline tomorrow (2013-01-29)
by Jaroslav Reznik
Hi!
This a friendly reminder that Fedora 19 Feature Submission Deadline is coming
soon - on Tuesday, January 29, 2013. After this date newly submitted
features will be targeted for Fedora 20 unless an exception is granted by
FESCo. So, think about the stuff you're working on if it deserves the broader
visibility within the release and submit it as a feature, see Feature process
Policy [1].
Proposals has to land ReadyForWrangler category tomorrow, so it could be
announced on Wednesday for the 2013-02-05 FESCo meeting. Ping me in case of
any questions.
For currently submitted features in this category - don't be afraid, all will
be processed and announced on time - a) you already have issues to fix in your
mailbox or b) I'm trying to announce features in parts not to spam devel-
announce at once.
Already accepted features as usually are available in the list on the wiki
[2].
Final Fedora 19 schedule based on submitted features will be available as soon
as possible and the scope is known.
Jaroslav
[1] http://fedoraproject.org/wiki/Features/Policy
[2] https://fedoraproject.org/wiki/Releases/19/FeatureList
11 years, 2 months
Proposed F19 Feature: MATE Desktop 1.6
by Jaroslav Reznik
= Features/MATE-Desktop-1.6 =
https://fedoraproject.org/wiki/Features/MATE-Desktop-1.6
Feature owner(s): Dan Mashal <dan.mashal AT fedoraproject DOT org>
MATE Desktop is based on GNOME 2 and provides an intuitive and attractive
desktop to Linux users who seek a simple, easy to use traditional interface.
== Detailed description ==
MATE is a traditional Gnome 2 like desktop user interface. Many users have
expressed interest in this feature since Fedora 15 in which Fedora was
switched from Gnome 2 to Gnome 3.
For the advanced user that doesn't want a cutting edge desktop and just wants
to keep it simple this is perfect for them.
The popularity of MATE Desktop is very high. It is one of the 2 choices of
DE's for Linux Mint which is one of the most popular Linux distros out right
now.
11 years, 3 months
Proposed F19 Feature: High Availability Container Resources
by Jaroslav Reznik
= Features/ High Availability Container Resources =
https://fedoraproject.org/wiki/Features/High_Availability_Container_Resou...
Feature owner(s): David Vossel <dvossel(a)redhat.com>
The Container Resources feature allows the HA stack (Pacemaker + Corosync)
residing on a host machine to extend management of resources into virtual
guest instances (KVM/LXC).
== Detailed description ==
This feature is in response to the growing desire for high availability
functionality to be extended outside of the host into virtual guest instances.
Pacemaker is currently capable of managing virtual guests, meaning Pacemaker
can start/stop/monitor/migrate virtual guests anywhere in the cluster, but
Pacemaker has no ability to manage the resources that live within the virtual
guests. At the moment these virtual guests are very much a black box to
Pacemaker.
The Container Resources feature changes this by giving Pacemaker the ability
to reach into the virtual guests and manage resources in the exact same way
resources are managed on the host nodes. Ultimately this gives the HA stack
the ability to manage resources across all the nodes in cluster as well as any
virtual guests that reside within those cluster nodes.
11 years, 3 months