Where we are and where do we what to go?

[Hans de Goede]

Thorsten Leemhuis wrote:
> 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.
> 

Great!

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

Yes I'm quite happy with things how they are :)

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

Your to critical I'm quite happy with the steady trickle of new contributers, 
welcome all!

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

True, but for the most part that is because things are in a reasonable state, I 
must agree there are some things below which we should work on.

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

Yes we really need that, wasn't someone looking into that, so who do we nag?

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

Not voluntereering to release manage this, but I do think an EL repo would be 
good, when I've some time I want to push gstreamer-* there.

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

Yes we seem to have a number of SOF on the human side, we need to fix that :)

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

Yes even more SOF's we need volunteers here! (not me I'm only a package monkey :)

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

Well kudos to Andreas for atleast keeping it somewhat sane, thanks Andreas, oh 
and also thanks for all the review work!

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

Maybe for some things, but I wouldn't want to claim we are the cannot be 
answered by Fedora FAQ answerer, and then in the FAQ say there are lots of 3th 
party repos, and you should only use rpmfusion.

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

Ack, I'll happily give up my seat / disband the whole current committee if 
there are some people who want to really do this on a regular basis.

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

I think that would spread us to thin, focus is important, I think it is 
important we define out goals clear, see below.

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

Yes!

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

An announcement list would be good.

> - 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, ...)
> 

I recently accidentally got a system with an nvidea, and the packages are 
excellent, what we need is docs and PR.

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

This might be one of those things which we just cannot fix a 100%, maybe we 
should learn to live with it?

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

I was very happy to see Rahul do some work here, way to go Rahul! I don't care 
much if the remix is an official part of rpmfusion or not.

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

Yes,

To me the goal of rpmfusion should be: The one stop place to go for getting any 
software which cannot be distributed as part of Fedora proper. This translates 
in to getting more packages in to the repo's, or even better getting more repos 
to join as our nr 1 priority.

> = 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 a smaller helper app to enable adobe and livna would be very good to have, 
when we do this semi automatically installing freeworld parts of already 
present apps would be nice too. Not another daemon please, just make it 
possible to rescan / redo this part.

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

Also sounds interesting.

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

Yes, the goal should be the one stop place for just working versions of 
software which can not be in Fedora proper :)

Regards,

Hans