Where we are and where do we what to go?

[Thorsten Leemhuis]

On 25.01.2009 20:07, Hans de Goede wrote:
> Thorsten Leemhuis wrote:
 > [...]
>> - 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!

Sure, I'm happy as well, I just had hopped for a bit more ;-)

> [...]
>> - 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?

I think Xavier once offered to look into that -- I remember I then 
stopped to look closer into this myself. Getting it to work is likely 
not that much of a deal, someone with the proper rights on the buildsys 
likely just needs to sit down and do it.

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

What I forgot to say: I'm willing to help with this. But someone else 
really needs to have the official hat on. That imho should also include 
to look at the usual channels and lists to watch out for problems users 
might run into.

> but I do think an EL repo would be  good,

strong +1

> when I've some time I want to push gstreamer-* there.

thx

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

I fear a bit that a new steering committee might revisit the libdvdcss 
issue immediately. That could bring the project into serious trouble, 
which I'd really like to avoid. It also would be kind of unfair if that 
decision would be changed quickly, as some people that invested a whole 
lot of time in RPM Fusion (like me) only did so because libdvdcss was 
left out.

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

Sure, there are risks. But it could bring lots of new contributors and 
help to get 3rd party repos merged into RPM Fusion. Especially the 
latter is appealing IMHO.

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

Sorry, I totally disagree here. If something requires docs to be used 
then it's IMHO partly broken already.

Just Look at fedora-list, where especially in the 
october/november/december timeframe a lot of people run into problems 
with our drivers.

Further: I also saw three of my colleagues (one quite familiar with 
Fedora; the other two not so, but they are real Linux experts) try to 
use the drivers. All of them failed somewhere and all ran into different 
problems.

But yes, work is done to make things better. But there is still a lot of 
work to do afaics.

>> - 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, this can't be fixed 100%, but it can be made a lot better, as most 
of the times things are on the servers -- yum just chose not-up2date 
mirrors. Maybe a yum plugin could do the trick and make it work in 99,9% 
of the cases. For the start enabling skip-broken would make things less 
problematic.

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

In my experience having such things outside the project IMHO leads to 
confusion among the users; sooner or later others might start creating 
their own RPM Fusion spins, which often lead to competition instead of 
cooperation :-/

 > [...]
>> = 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.

Well, a daemon might be best to work automatically and flawlessly. But 
maybe a yum plugin could work as well.

IOW: Users should not have kick a tool to rescan the system; it should 
"just work" automatically, to make sure it works for people that are not 
familiar (yet) with Fedora.

 > [...]

CU
knurd