Where we are and where do we what to go?

[David Timms]

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.