Goals

[Thorsten Leemhuis]

Hi!

I read over the "Where we are and where do we what to go?" thread again 
and tried to create a page in the wiki that lists some generic and some 
specific goals that RPM Fusion may want to achieve. See
http://rpmfusion.org/Goals or the text below.

Comments? Did I miss anything?

CU
knurd

P.S.: Reminder, it's a wiki for a good reason; so if you want to add or 
improve something go ahead and do it straight in the wiki

P.P.S.:Special thx to Stewart Adam for quickly reading over the text and 
fixing lots of mistakes I made.

---

= Goals =

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>>

== 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 
[http://fedoraproject.org/wiki/Packaging/LicensingGuidelines|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 similar 
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 tradeoffs 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 tradeoffs 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 then 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 build in a part of the world 
where host 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-readhat integrated into RPM Fusion as a dedicated new repo

  * start a 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 ===

==== 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 save). The app should have a command line 
interface to be scriptable. And in the default usage the GUI  should not 
ask to 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 of the install helper?) 
could 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 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 be have a newer 
xine-lib-extrs-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 on 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 
inoffical official 3rd party repo for Fedora, but also be the offical 
3rd party source for all the docs that can't go straight to Fedora?

==== 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; no real planet.rpmfusion.org or other 
way to get important information out to the users

  * 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?

  * improve docs for contributors and users; document processed

  * 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 at cvs.fedora.redhat.com:/cvs/extras'
alias cvsrf='export CVSROOT=:ext:USERNAME at cvs.rpmfusion.org:/cvs/free'
alias cvsrnf='export CVSROOT=:ext:USERNAME at cvs.rpmfusion.org:/cvs/nonfree'
}}}