Where we are and where do we what to go?

[Thorsten Leemhuis]

Hi!

It afaics can help a lot to now and then step back for a moment and try 
to look with at where we are some distance; after that it's often the 
time to think about where we want to be in one, two or five years from 
now. I tried to do that over the last few days; find my thoughts below.

One note: consider to stop reading this mail *now* temporary and instead 
quickly and roughly write down a few of your own thoughts of where RPM 
Fusion is and where it should head to. After that continue to read this 
mail -- if you find that some of your thoughts are missing in below list 
consider to send them to the mailing list for wider discussion.

= Where we are =

- we started a few months ago and it worked out quite well afaics; right 
now the repos and the packages in it might not be perfect, but the repos 
overall were and still are in acceptable good condition

- since we started we got some new packages and a few new contributors; 
that's good, but in fact I had hopped the numbers of new contributors 
would be a little bit higher

- 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

- no automatic dep check script running that makes sure our repo is in a 
sane state; that is something we really need!

- 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" (I'm doing that job a bit for 
the Fedora repos; someone else, that actually uses EL more than I do 
should do it for EL; BTW, where did all those go that were interested in 
supporting EL as they maintained their own rpmfusion/livna rebuilds for 
EL somewhere already)?

- Xavier is the only one that takes care of the infrastructure (don't 
count me, I don't want to do it the infra things I do now and then); 
that's bad and needs to change; we actually had one or two (maybe more) 
serious offers from people that wanted to help, but nothing happened, 
which afaics was at least partly our fault

- we have only one person that has access to the signing keys, their 
pass-phrase and the buildserver; that makes some things easier (no 
coordination needed), but is a single point of failure (/me wonders why 
nobody yelled yet about this; seems nobody is interested in things like 
that, which might mean that this mail likely won't get much attention 
either). We at least should have one (better: two) additional signers 
(they of course need to be trustworthy; being on IRC a lot would make 
coordination easier) -- ideally at least one of them should be located 
in a timezone that is a bit away from Europe

- knurd is also the signle point of failure for the buildsys, as only he 
has access to the actual builders; that will be changed for one of the 
x86 builders soon;

- thias (who sometime is hard to catch) is the only one that can change 
DNS in case that's needed

- pushing the free repo can take quite some time (an hour? never 
measured the exact time); would be nice to speed things up (NFS might be 
the bottleneck that slows things down), but that's just a detail

- a good bunch of mirrors and a nice infra to manage them; what are 
those "metalink urls" that fedora recently started to use for the alpha? 
should we use those in the future as well?

- parts of the wiki need a cleanup; ideally somebody would constantly 
watch and take care of the wiki as a whole

- some of our processes are afaics not documented at all or not properly 
documented

- documentation in general: 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?

- there is a small steering committee, but that doesn't meet and until 
now was rarely used; having a real one (or simply a loose group of 
people that want to improve RPM Fusion) that regularly meets on IRC 
could help bringing the project as a whole forward

- some ideas for new repos were mentioned (staging; unstable; someone 
iirc also mentioned the idea to get kde-redhat under the hood, which 
could have benefits  for both sides), but nobody drove those ideas forward

- still lots of other 3rd party repos out there; users still run into 
problems as they try to mix incompatible repos; should we actively try 
to get more repos merged into RPM Fusion?

- rpmfusion-buildsys broken; no announcement mailing list; no real 
planet or other things to get important information out to the users

- out graphics driver packages seem to have not a real good reputation: 
users accidentally remove the stuff that is needed in xorg.conf with 
tools like ati-config, nvidia-xconfig, ... and hence break the drivers. 
Users are also confused by the different drivers; many don't know which 
one to choose (legacy, 96xx, 173xx, beta, ...)

- kmods for new kernels nearly always get pushed within minutes after 
the new kernel got out. But the rebuild is still manually kicked of. Not 
much work left to fully automate that work; knurd just needs to sit down 
and do it; pushing will stay manually in any case (for this a second 
signer in a non-EU-timezone would be ideal). But:

- 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, but I don't know how and my 
questions how to fix this seemed to get ignored by skvidal :-/

- handling of kmods for PAE and other special kernel variants could be 
easier; no big problem, but it needs to be easier in case -PAE kernels 
become default for i686 (see recent discussion on fedora-kernel-list)

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

- should we have a page "this are the goals we want to archive with RPM 
Fusion" in the wiki somewhere? That afaics often helps to get people 
together and work towards realizing those goals

= Where we want to go =

The "where we are" part already had some areas and suggestion where 
things need to be improved; here are some more:

- it would be really nice to have a small helper app that is used for 
enabling RPM Fusion and initial configuration. E.g. users could download 
that helper app rpm instead of the two release-rpms (or it 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-nonfree if 
xine-lib is found; same for gstreamer-plugins, k3b and others; this 
maybe should be done by a daemon later as well to keep things smooth); 
maybe this helper app could even enable livna, but that might be tricky 
as the livna repofile must not be in that package (I guess retrieving 
the data from the net OHOH should be save) .

Yes, I'm fully aware that such apps that do parts of this exist already. 
But some do stupid things and everyone could benefit from a sane app 
official app in RPM Fusion.

- 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 driver to choose" part easier

With something outlined as roughly above we in the end could provide a 
solution that "just works" -- install Fedora, download helper-app from 
RPM Fusion, ask a few (max. something like 5) unavoidable questions, 
wait a few minutes, fully working system with all the user wants.

- switch to koji, bodhi, packagedb -> Xavier iirc is thinking about that 
and maybe doing some preparation for that; would be nice to switch, but 
no need to hurry, current setup works

= EOF =

That all from my side. For now (I guess I forgot a few things and those 
will come to my mind as soon as I hit the "send" button). But whatever:

I'd be interested in your ideas and comments on the above; then we 
should work out which things we'll try to work on in the near future

CU
knurd