11:53 a.m.
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