Hans de Goede wrote:
Thorsten Leemhuis wrote:
...
= 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 :)
I agree with that. Do our users agree ?
- can we count how many users we have ?
- can we count how many updaters we have ?
- could we get such info from the mirrors ?
- before the above, do people consider getting such info out of web
logs to be an invasion of privacy ?
- 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). 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.
- 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.
We could look at this as "what would make rpmfusion the 'killer app'
that essentially every user immediately enables after a fedora upgrade
or install ?".
- dvd playback ?
- mp3 playback ?
- closed source graphics driver support ?
- 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
...
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.
For me, I don't use centos/el anymore at work nor home, so I'm reluctant
to build something for it, since I don't really know the differences,
and (if we don't already) we should have some info regarding such
differences, update mindset, stability mindset of the people that use EL.
One way could be to give a time frame of say 60 days from the EL release
or major update (or even maybe fedora release, since it seems common for
about a gigabyte of Fedora and RF updates to be needed within a month or
two of a Fedora release) to have completed integration repo testing and
then what is ready becomes the rpmfusion release for that version.
Other things I don't know about EL:
- do the public have access to a continual stream of rawhide packages
like fedora ?
- do the public have access to beta releases ?
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. I
think there is also some kudos involved like - what experience do you
have admining linux systems? - I built and maintained an rpm packaging
repo for 20 packages.
There is possibly also some issue of trust eg: if I am using EL for
work, then I might need to guarantee any packages used are of sufficient
quality and free from potential exploits etc. The only way I can do this
is get the source and build it myself. ie there is no RedHat support
saying this package is good. How would you build such a reputation for
RPM Fusion ?
I think the best bit about packaging for Fedora or RPM Fusion is the
interaction with reviewers. This can help a packager go from 'this seems
to work for me' to 'this works for at least two people possible on
different architectures' to 'this is a much better package now that more
eyes have been across it'. Even the comments from brand new packagers
/reviewers are helpful to pick up things that I have missed.
- 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 :)
Not sure of http://www.answers.com/topic/sof but thinking you are
meaning single point of failure ?
- we have only one person that has access to the signing keys,
...
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
- the person(s) has actually checked the diffs of packages to ensure no
skulduggery [1] is occurring.
[1] http://www.merriam-webster.com/dictionary/skulduggery
- 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!
I usually take an interest in this - and am happy to update pages when
rpmfusion-users or fedora-list people make mention of something
specific, or needing attention.
- 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.
Although, having more repos active seems to have a detrimental effect on
yum/PK operation time, and it would likely confuse users.
- 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.
- 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.
- 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, since it
essentially delays the smallest conflicting part of the update until it
is available, all your other security updates still get installed.
I had suggested that --skip-broken (or perhaps another plugin) could
understand that the fact that a potential download that is actually not
currently downloadable should be treated as a 'broken' update, so that
transactions can complete.
b) mirroring could be a two stage process (or at least we could treat it
as such from the supply point of view):
- publish the rpms earlier, (potentially automatically from the build
sys). Do not replace the earlier released rpm yet.
- once enough time has gone by that a heap of mirrors have the packages
(24? hours), build the repo metadata and publish it (possibly with both
old and new packages visible).
- after 24? hours remove the superseded packages from the master.
Would that be workable ?
- 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.
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).
- should we have a page "this are the goals we want to achieve with
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.
I also like the mantra of 'just works' for a user. It is interesting
though that the more repo work that gets done that makes it easier for
the user, the less likely that the user might be driven to find the time
or energy to enage with the project/community in any other way other
than consumer. (sort of like success may in fact be shooting yourself in
the foot). Is no complaints a reflection of 'no problems' or can't be
bothered (didn't work, too hard, don't want to subscribe) ?
= 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. 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.
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.
= Goal of RPM Fusion =
I would like to think that one goal could be:
"reduction of fedora-list traffic"
Let's say that shortly we have:
- a super system for getting closed source drivers easily installed and
optimized.
- an easy way to ensure most multi-media stuff just works
- an easy way to install some proprietary apps (vmware, flash, skype
seem to be regularly discussed/need help with etc).
{i'm thinking hal and PK integration)
Maybe that would cut down on 10-20 % of that lists traffic !
= kmods in the repo =
Do we want to store the complete set of built kmods forever ? These are
sort of multiplicative - if they aren't already, it won't be long before
released kmod variants exceed actual packages in number.
Could we assume that all older kmod releases are redundant since they
can be built on the user's system with akmod ? And hence remove them
from the repo ? Maybe just keep the latest 2, plus the one from Fedora
release time ?
Cheers (hope I didn't bore you with this), David Timms.