Where we are and where do we what to go?

[Hans de Goede]

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