WishList

Currently unscheduled Development Areas and Ideas for Fedora

This page lists suggestions and ideas for Fedora that are currently unscheduled, but might be worked on in the longer term. If you want to add something: Nothing silly like "let's remove {KDE,GNOME}", or "dump evolution and openoffice.org" please.

If you want to request software packages for see Fedora package Wishlist

Items where community members can take a leading development role

Red Hat does of course have a significant influence over the direction of development of Fedora through the assignment of engineers to work on development tasks important to Red Hat's customers. Not all potential features are compatible with the overall direction of development in Fedora. However, there are items that a subset of the community would like to see more development on, but for which there simply aren't enough developer manhours to address. Some achievable, compatible features have to be given low priority compare to other interests by individual developers. In these cases strongly committed community members can take a leading role in bringing a low-priority but popular feature into fruition.

Below is a short list of some areas in which community could take a development lead in if they are strongly committed to working with upstream and with Fedora developers by providing patches for intergration and testing. The x86_64 and especially the PPC ports of Fedora is a shining example of what community development dedication and skill can accomplish when community members step forward and work with developers.

• Installer options for Reiserfs, JFS in anaconda is present but not supported by the Fedora project and currently the community has not stepped up to take over maintainance of these and bring it up to a supportable level. See Install Guide also for "unofficial" kernel parameters

• More minimal, minimal install - no nfs/portmap/ypbind/X/httpd/etc... but have yum at least so that once a minimal install is done, a user can use yum to pull packages that are required down, and not have to uninstall packages; This entails re-structuring the Fedora comps.xml to reduce the minimal install packagelist, without changing the desktop, server or workstation install types or changing the user viewable list of package groups.

• Each user being able to change languages for newly started applications in mid session. Maybe a GUI tool to set the LANG= variable? A Panel applet?

• Updated Installmedia with all released updates ~3 to 4 month after first shipment. http://fedoraunity.org does this now.

There is a fedoranews-article

Resourced goals

• Stateless Fedora -- Red Hat has alloted engineering resources for this. Will be available as part of Fedora in a subsequent release.
• revamped installer/firstboot (reconsider what needs to go where, how Xen works eg allow to make a golden image you can clone but customize on bringing that up first time, hook it into yum to update the system during firstboot, work with extras nicer, optimize the speed, figure how to have system-config-packages merged in, do minimal install and let firstboot finish it etc etc)

Undecided things

• i386 and x86_64 on one (double-layered?) DVD
• system-config-role; ML thread some setup tool where you could select a machines role using profiles for Laptop (ACPI, NetworkManager etc), Workstation (nothing special), LAMP server (setup apache, mysql, and PHP in a sane way), File/login-server (LDAP, NFS, Samba)
• central folder/tool where all system-config-* are found (to satisfy drakeconf and yast users)
• supported way updateing from FC X -> FC X+1 via yum
• MartinJürgens: I support this as it will push Fedora on the end-user desktops. Hardware vendors currently probably think that Fedora is no solution for their customers because it is not security-maintained for a long time. If it would be easy to users to update their system on the fly, this would dramatically change. A notification in Pirut would be nice saying "A new release is out". After clicking some buttons, the system should begin to update.
• Bandwidth friendly updated using binary delta algs
• MartinJürgens: See FeaturePresto , it says that it will be enabled in Fedora 9 by default.
• avoid redundant libaries in apps (for example most gnome apps right now have 2 XML libraries loaded and in use)
• Graphical shutdown
• MartinJürgens: Maybe FeatureBetterStartup , I added a comment regarding the Shutdown of the system.
• Ship Cups-PDF by default - see https://bugzilla.redhat.com/show_bug.cgi?id=136565
• Make the Anaconda Grub Installation Module able to detect Windows and other Linux Distributions automatically and propose GRUB entries for them.
• Better help system: Improve yelp for both GNOME and Fedora documentation so that it checks for newer documentation available if an internet connection is available. This could be useful if there are, for example, updated documents or documents in the users' language of choice available. There could be also a knowledgebase (maybe at GNOME) be created with tags so that when the user searchs in yelp, he is also displayed information that has been added by users (of course there should be good QA). Another idea that I have is that documents can be tagged to the GNOME version, like if nothing has changed in 2.20, the same document is displayed in version 2.20. If something has changed, a new document is being created only tagged with 2.20.

Please file Bugzilla for those

• more sudo usage / preconfigure it and ask during user creation if the user should be allowed to to admin-tasks

Things that should probably happen upstream

• For people with a home network, easy GUI setup so that RPMs are downloaded only once (something like a yum-proxy?)

Dag Wieers [http://dag.wieers.com/home-made/yam/ yam ]* Proxy/Network Changes should be send via DBUS or something like that to bash

Things that probably won't happen

• See Forbidden Items for a list of things does not currently meet Fedora project's licensing and patent requirements

Things that always happen

• lower memory footprint