Where we are and where do we what to go?

[Thorsten Leemhuis]

On 26.01.2009 01:05, David Timms wrote:
> Hans de Goede wrote:
>> Thorsten Leemhuis wrote:
> ...
>>> - 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 :)
> I agree with that. Do our users agree ?
>    - can we count how many users we have ?

No, I only have access to the awstats from download1.r.c

>    - can we count how many updaters we have ?

updaters?

We might be able to check how many people hit mirros.rpmfusion.org, but
- those are two or three machines as well
- not everyone uses mirrormanager

>    - could we get such info from the mirrors ?

Don't think so.

>    - before the above, do people consider getting such info out of web
> logs to be an invasion of privacy ?

Checking the number of visitors shouldn't be a big problem.

But in general: putting a privacy policy somewhere in our wiki (simply 
copy the one from Fedora?) might be a good idea.

>>> - 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!
> And for most serious packages, it is not a breeze to bang up a .spec and
> get it reviewed (mine took around a year from my first work on a spec
> until finally ready for inclusion).

Related: What I'd really like to prevent is that our list of unassigned 
review-bugs gets to long...

> But I far prefer this than having a
> zillion app users configure, make, make install packages they find on
> the net. We do need to ensure that all reviewers do so in a positive
> frame of mind, rather than being abusive or dictatorial in their
> responses. We don't want the packager to be put off, neither do we want
> other readers of the review (eg from a mailing list archive when a user
> does a search for something) to think that being part of the RPM Fusion
> sounds bad / is a stress etc.

+1


> [...]
> Other things I don't know about EL:
> - do the public have access to a continual stream of rawhide packages
> like fedora ?

No, there isn't something like a "EL-rawhide"

> - do the public have access to beta releases ?

In the past that was the case.

>>> 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)?
> Perhaps it is too easy to createrepo and publish somewhere on the web.

Yes, definitely ;-)

 > [...]
>>> trustworthy; being on IRC a lot would make coordination easier) --
> Trustworthy is the key of course. We (both users and packagers) need to
> be confident that:
> - the key won't go missing
> - the key won't be used except as needed by rpm fusion signing process

Agree to these.

> - the person(s) has actually checked the diffs of packages to ensure no
> skulduggery [1] is occurring.

No, but that's not the case -- the signers in Fedora or RPM Fusion trust 
that the tarballs and patches that get uploaded by the packagers are good.

 > [...]
>>> - 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 too thin, focus is important, I think it
>>  is important we define out goals clear, see below.
> Agreed.
> In terms of the earlier mentioned issue of push time, would it make
> sense (or even save time?) to have an 'updates-bulk' (think of a better
> name) repo. This could once a month or so, take all 'updates' as we
> currently know them and split the repo into all changes from release to
> this point in time. Any new updates during the intervening month could
> be in an 'updates-recent' repo, so that user machines only have to
> download repo metadata of a size related to the changes within a smaller
> timeframe.

We already have updates-testing, where new and updated packages normally 
stay for 7 to 14 days. That should be enough afaics.

>>> - 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!
> I haven't been on lists etc where users are having such trouble recently
> (actually one I did suggest going with RPM Fusion rather than a
> troublesome combination of 4 other external repos.

There was someone on fedora-list recently that had trouble, as he had 
atrpms and rpmfusion enabled.

>>> - 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.
> Never noticed that, how wide spread is it. Does the issues lend 
> themselves to improvement of packages or other areas. Isn't Stewart's 
> work on this nearing completion ?
> 
> Anyway, 'just works' for me on nvidia fx5600.

It afaics just works if you just stick to the defaults. nvidia-xconfig 
for example afaics doesn't work, but is something a lot of people would 
like to use.

>>> - 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?
> a) The simplest solution is default use of --skip-broken, [...]

I'd call it a workaround and not a solution, but yeah, it would hide the 
proble

> b) mirroring could be a two stage process (or at least we could treat it
> as such from the supply point of view):[...]

That is to complex to realize -- especially as it would require support 
in Fedora.

>>> - 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.
> Another one of those 'so much to do - never gets done' items. I wanted
> to take a look at it but never got the time. Stuff like this really
> needs multiple eyes (aka reviewers/testers) who can pass both a
> technical and critical eye over the remix and provide positive feedback
> to the developer.

+1

> Keeping a 'supported' remix or two within the project, and potentially
> distributed on rpm fusion mirrors would be a good thing, even if only to
> centralize the work in this area (outside of the pure Fedora world).

+1

> [...]
>>> = Where we want to go =
> ...
>>> 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.
> We don't really want to get users used to downloading and running raw
> apps from the internet - even our own. 

Well, I don't think that's a huge difference to what
http://rpmfusion.org/Configuration already does.

> I suggest sticking to the signed
> repo, signed packages approach, but other wise this is a good idea. With
>   some stats from download mirrors, we could become better informed in
> what users actually install / setup on their system.

Users still would need top know what to do after enabling RPM Fusion to 
get a fully working system. And that's imho not good and not what we want.

They have to trust us and our packages anyway already. So why not with a 
helpful installer?


> New:
> = Package suggestions =
> I like to keep an ear (eye) out for apps that the linux media is talking
> about, and I usually check out the home page, and put such into my 'when
> I get time' bookmarks.
> 
> An 'In The News' or 'Recently Talked About' section could provide
> potential packagers with a list of suddenly publicized packages.
> - eg: a linux journal article runs on a topic like 'audio production'.
> It mentions 5 different apps, and how to configure/make/make install for
> those apps and get them going. Then talks about actual use of those
> apps. (This also applies to some threads on the fedora-list).
> 
> Our response could be to:
> - as soon as possible get it in our list (just to keep track - it might
> eventually make it into fedora if it can).
> - hopefully quickly find an interested person to mark it as 'beginning
> packaging'
> - review, accept, import, build, release the package.
> - see that the referring article actually works with our packages.
> - create a page devoted to that application, with a link to the original
> article, the project page, additional information pertinent to
> fedora+RPM Fusion.
> - hopefully by the time fedora users are reading the article, they can
> yum install somecoolnewpackage and be on their way to following the rest
> of the article.

Isn't this something that should started in Fedora? Then we can handle 
the parts that Fedora can't.

> = Goal of RPM Fusion =
> I would like to think that one goal could be:
> "reduction of fedora-list traffic"

I'd prefer something like "Make it just work" ;-)

> [...]
> = kmods in the repo =
> Do we want to store the complete set of built kmods forever ?

That's not the case. I know and then remove old ones manually. But I 
need to be careful to not remove the akmod packages while doing that. I 
also cleaned the F8 repo when it went EOL.

But I can clean more aggressively if people want.

CU
knurd