Re: Where we are and where do we what to go?

Hans de Goede wrote:

> 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.

>> - 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.

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).

= 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)