David Timms wrote:
Hans de Goede wrote:
<snip>
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 ?
Yes.
- 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.
Thats great, thanks!
- 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.
-1, because:
Although, having more repos active seems to have a detrimental effect on
yum/PK operation time, and it would likely confuse users.
<snip>
- 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.
Yes getting skip broken to be enabled by default would be good.
<snip>
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).
Sounds like a good plan!
<snip>
= 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)
I would rather see "reduction of fedora-list traffic" as a result then as a
goal itself.
Regards,
Hans
