This page lists the general goals of RPM Fusion as well as specific work areas the members of the project are planing to or work on or already work on to reach the general goals.
<<TableOfContents: execution failed [list index out of range] (see also the log)>>
Overall
Become the de-facto "official" Fedora add-on repository for all legally distributable free and non-free software the Fedora project doesn't want to ship. That software should be packaged in the same packaging format that Fedora uses and should not require deeper knowledge to install and use. In other words, make FAQs and howtos obsolete as much as possible by making things "just work". Avoid to do things where we would compete with Fedora, and while building and maintaining the repositories try to match Fedora when it comes to rules, guidelines, procedures and infrastructure as much as possible.
More detailed overall goals
The paragraph above outlines the overall general goals (call it "meta goals" if you like) quite well, but (intentionally) doesn't go into the details. The following points are a few examples that in a more verbose way try to outline the RPM Fusion's general goals:
provide software that is free (as defined by the Fedora licensing guidelines) as pre-compiled RPMs for Fedora and RHEL/CentOS + EPEL in a yum repository that seamlessly can be used by the packaging tools from Fedora during and after install; packages in that repo should not automatically replace packages from the distributions the repo is designed for
- provide distributable non-free software (anything that is not "free" according to the Fedora guidelines) in a different repo that is similarly styled to the free repository
- rely on the packaging or update guidelines from Fedora for RPM Fusion as much as possible; only enhance/adjust those rules in areas where it is needed for the specific nature of RPM Fusion
- when possible, don't do things in RPM Fusion that could be done in Fedora, as doing it there is better for everyone (albeit sometimes harder to realize)
- try to get more repos to merge into RPM Fusion
- make RPM Fusion package repositories as well as the packages in it as easy to use as possible (e.g. make it "just work") to make sure that computer, Linux, or fedora newbies have an easy time getting those things that Fedora doesn't want to support to work.
Note that RPM Fusion as well as its contributors have to obey laws in their area of operation and hence can't do everything they would like to do, so trade-offs had to and have to be made. That was (and is) hard, but necessary -- otherwise RPM Fusion maybe wouldn't have lift of at all and definitely would have a smaller contributor base.
One of those trade-offs is: we don't ship software that is not re-distributable and we avoid one well known open-source package used for playing DVDs as that is known to be more problematic than other software we ship. RPM Fusion hopes that sooner or later a different repository (that works on top of RPM Fusion just like RPM Fusion builds on top of Fedora and RHEL/CentOS + EPEL) is built in a part of the world where hosting such a repo isn't a problem.
Specific work items
The members of the RPM Fusion project are well aware that RPM Fusion in a lot of areas doesn't reach the goals outlined above. So there are several things that are done or under discussion, as well as lots of ideas to get closer to a point where we reach the goals.
Ongoing work
automatic dependency checking script
Xavier is working on that
Ongoing work that could need help
improvements for graphics drivers
The RPM Fusion-packaged graphic drivers from AMD and Nvidia are well known and respected among some users. But there is still a lot of room for improvements:
- users have to know which driver they need and that confusing people
- the tools from AMD and Nvidia don't work too well; sometimes they remove important parts specific to our driver packages from xorg.conf and thus break 3D
- Fedora uses very recent kernels and so often, the kmod packages won't compile; help from someone with lots of kernel know-how would be very appreciated.
EL repo
We need to decide if we let this lift of or drop it now before it started for real. Yes, some packagers like the idea and maintain their packages for the repo, but that's not enough for a repo to last; for the EL repo to really lift of we need someone that takes care of it as kind of "release manager" (ThorstenLeemhuis is doing that job a bit for the Fedora repos; someone else, that actually uses EL more than he does should do it for EL)?
new repos
There are multiple ideas that are slowly discussed:
- get kde-redhat integrated into RPM Fusion as a dedicated new repo
- start an experimental repo with updates that are not ready for updates{,testing}
- start a staging repo with unreviewed things (only license check)
- a repo with packages that replace packages from the distribution they were build for)
This is being discussed slowly but there has been no conclusion on the issue yet, nor any work being done to realize it. Once that is solved it might make sense to go out and actively try to get more 3rd party repos merge into RPM Fusion
switch to koji, bodhi, packagedb
Xavier iirc is thinking about that and doing some preparation for that already; would be nice to switch, but no need to hurry, current setup works
Ideas nobody is working on
[musuruan: is it feasible to have some of these ideas as GSoC?]
Installer
A small helper app that enables RPM Fusion (and other repos?) and does the initial configuration (e.g. install xine-lib-extras-nonfree if xine-lib was found to be installed earlier).
Detailed description: Users could download that helper app rpm instead of the two release-rpms they have to download not (or the helper app could be part of the rpmfusion-free-release rpm). That helper app then could ask a few questions like "Do you want 'nonfree' packages?" or "do you want to enable compatible repos like the adobe repo?". After that it could act according to what the user wants and what's found on the system (e.g. install rpmfusion-nonfree-release; install xine-lib-extras-freeworld if xine-lib is found; same for gstreamer-plugins, k3b and others; import keys for the repos). Maybe that installer should remain active on the system and tell the users that he might want to install xine-lib-extras-freeworld when he installs xine-lib; but maybe that better done by a yum plug-in or a combination of those two. But users should not have to manually "re-scan" the system.
Maybe this helper app could even enable livna, but that might be tricky as the livna repofile must not be in that package (retrieving the data from the net OHOH should be safe). The app should have a command line interface to be scriptable. And in the default usage the GUI should not ask too many question that might confuse people that are new to linux -- it should "just work" 
Yes, apps that do parts of this exist already (like Autonine/Autoten). But some do stupid things and all ask way to many questions. And everyone could benefit from a sane official install that is provided by RPM Fusion
Jockey for Fedora
Another small app (either tied into or separate from the install helper?) could do things similar to the one jockey does in ubuntu (see https://launchpad.net/jockey and http://people.ubuntu.com/~pitti/screenshots/jockey/ ). Firewing1 is thinking about doing something like this already (which likely will mean: port Jockey to Fedora), which should make the "users don't know which graphics driver to choose" part easier. But the goal should remain: make things "just work", so no configuration options if they are not strictly needed.
mirror lag / skip broken by default
RPM Fusion packages with hard deps on Fedora packages (kmods, xine, qmmp, audacious, ...) often create lots of problems for Fedora users due to mirrors lags (RPM Fusion mirror might have a newer xine-lib-extras-nonfree while the Fedora mirror yum doesn't have the matching xine-lib yet or vice versa; details: https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html ) we really need a solution for this
kmod-plugin
There is a plugin for yum that should improve handling of kmods; that plugin needs adjustments for the current kmod scheme to automatically install the PAE kmod if a PAE kernel is installed (and perhaps to deal with akmod-generated kmod packages in a better way)
form a real steering committee and meet regularly
Activity to improve the project as a whole (not meaning the repo or the individual packages) went down a lot since we started 
we just do "business as usual", which might be very dangerous in the long term. Would a steering committee help? Or how can we make people feel comfortable to "just do things" to improve RPM Fusion without being on a steering committee?
improve reliability of RPM Fusion
We have lot's of "Single Points of Failure" within the RPM Fusion project -- hardware without backup systems or plans how to keep things running in case of a problem; only one person has access to things like DNS, buildservers, or signing keys
improve the docs
There are lots of FAQ, Howto and other docs on the net that describe how to use RPM Fusion; often those are misleading, not fully right, outdated or they disagree with each other; should we try to not only be the unofficial official 3rd party repo for Fedora, but also be the official 3rd party source for all the docs that can't go straight to Fedora?
[musuruan: can we have a synergy with 3rd party doc sites? Fedora FAQ and Fedorasolved comes to my mind.]
automatically rebuild all kmods
ThrostenLeemhuis has a plan how to do that; it's not that hard, he just needs to sit down and do it
misc
- rpmfusion-buildsys-list is broken;
- no announcement mailing list (low traffic);
[musuruan: what is the problem in having one?]
- no real planet.rpmfusion.org or other way to get important information out to the users.
[musuruan: I can configure a planet if someone else provides an host, but I can't see the difference from planet.fedoraproject.org, after all we are Fedora contributors too.]
- Chris Nolan was working on using wordpress to publish news. The integration with FAS has already been done it was working. Project stalled when requesting a valid SSL certificate for the domain. No further updates.
- no RPM Fusion Fedora remix maintained within the project; do we want one? Or even proper install DVDs that already contain packages from RPM Fusion?
[sunset06: can we build a ~non-intrusive~ instal dvd that uses all the normal fedora stuff, but maybe via a kickstart file adds the RPM Fusion repo defs, and as many useful rpm packages that still fit within one DVD, and default installs a few choice packages ?]
- improve docs for contributors and users; document processed
[musuruan: can we look for more contributors in the fedora-docs-list?]
- a small script or rpmfusion-packager package with a script that does things like
alias plague-client-rf='PLAGUE_CLIENT_CONFIG=~/.plague-client-rpmfusion.cfg plague-client' alias cvsf='export CVSROOT=:ext:USERNAME@cvs.fedora.redhat.com:/cvs/extras' alias cvsrf='export CVSROOT=:ext:USERNAME@cvs.rpmfusion.org:/cvs/free' alias cvsrnf='export CVSROOT=:ext:USERNAME@cvs.rpmfusion.org:/cvs/nonfree'
we need a place where to host RPM Fusion projects. Something like Fedora Hosted.
improve the appeal of the wiki. If we continue to use moinmoin, we could adapt this design used by CentOS.