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