Where we are and where do we what to go?

[Stewart Adam]

On 1/25/09 1:33 PM, Thorsten Leemhuis wrote:
> Hi!
>
> = Where we are =
Where we are now is a good start and if we continue on the same track, I 
think things are only going to get better...

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

> - no automatic dep check script running that makes sure our repo is in a
> sane state; that is something we really need!
I'm interested in doing this, but I'm not sure when I'll actually be able to 
get around & what the requirements wrt the build system are. IIRC somebody 
linked to a python script that did this on fedora-devel-list not so while 
back, maybe we can use that.

> - 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)?
Slightly offtopic, but part of the Wiki revamp should also include docs for 
how to maintain a packages in the EL repos...

> - 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
>
> - we have only one person that has access to the signing keys, their
> pass-phrase and the buildserver; that makes some things easier (no
> coordination needed), but is a single point of failure (/me wonders why
> nobody yelled yet about this; seems nobody is interested in things like
> that, which might mean that this mail likely won't get much attention
> either). We at least should have one (better: two) additional signers
> (they of course need to be trustworthy; being on IRC a lot would make
> coordination easier) -- ideally at least one of them should be located
> in a timezone that is a bit away from Europe
>
> - knurd is also the signle point of failure for the buildsys, as only he
> has access to the actual builders; that will be changed for one of the
> x86 builders soon;
>
> - thias (who sometime is hard to catch) is the only one that can change
> DNS in case that's needed
>
> - pushing the free repo can take quite some time (an hour? never
> measured the exact time); would be nice to speed things up (NFS might be
> the bottleneck that slows things down), but that's just a detail
>
> - a good bunch of mirrors and a nice infra to manage them; what are
> those "metalink urls" that fedora recently started to use for the alpha?
> should we use those in the future as well?
According to http://metalinker.org, it combines FTP, HTTP and P2P 
capabilities together for extremely fast download speeds, along with error 
checking and redundancy (if mirrors are bad, it can skip them + move on).

> - parts of the wiki need a cleanup; ideally somebody would constantly
> watch and take care of the wiki as a whole
>
> - some of our processes are afaics not documented at all or not properly
> documented
I've been wanting to bring this up - I think our /Contributors page needs 
some parts rewritten, and a bit more added in certain spots. We should also 
create a page with guidelines specific to RPM Fusion (kmods should be 
mentioned and licensing also comes to mind so we don't have libdvdcss all 
over again).

Also, I don't have a tremendous amount of experience using CVS so I may be 
completely wrong, but getting the CVSROOT right is annoying; I've put the 
following in ~/.bashrc to help:

* alias 
plague-client-rf='PLAGUE_CLIENT_CONFIG=~/.plague-client-rpmfusion.cfg 
plague-client'
* alias cvsf='export CVSROOT=:ext:USERNAME at cvs.fedora.redhat.com:/cvs/extras'
* alias cvsrf='export CVSROOT=:ext:USERNAME at cvs.rpmfusion.org:/cvs/free'
* alias cvsrnf='export CVSROOT=:ext:USERNAME at cvs.rpmfusion.org:/cvs/nonfree'

Maybe we should include this too in /Contributors?

> - documentation in general: there are lots of FAQ, Howto and other docs
> on the net that describe how to use RPM Fusion; often those are
> misleading, not fully right, outdated or they disagree with each other;
> should we try to not only be the inoffical official 3rd party repo for
> Fedora, but also be the offical 3rd party source for all the docs that
> can't go straight to Fedora?
If we want to go ahead with this, I've already setup the Wiki pages for that 
[1]. Package maintainers (or someone else, if the maintainer is OK with it) 
would just have to write a quick blub on their Package/PackageName page 
documenting any known problems, workarounds, etc - anything 3rd party howtos 
or documentation would normally mention.

> - 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
> - 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
>
> - 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?
I think so... One of my own thoughts about what we should be is a place for 
users to receive high quality packages that compliment the Fedora ones. 
IMHO, we should aim to be *the* place for users to get everything they need 
that's not included in Fedora.

> - rpmfusion-buildsys broken; no announcement mailing list; no real
> planet or other things to get important information out to the users
The managers at FedoraForum.org are pretty good at watching what's going on, 
so the users there get updates on the important issues but we should get a 
place where we consistently put all our announcements. Maybe a /News page on 
the Wiki?

> - 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, ...)
A lot of that is going to be fixed really soon - rpmfusion-config-display is 
under review now, and kwizart and I are working on modifying the nvidia 
tools to stop that from happening. At the same time as we fix that, I'm 
hoping we can also setup nvidia-settings with PAM. This way, it will "just 
work" for changing xorg.conf.

> - kmods for new kernels nearly always get pushed within minutes after
> the new kernel got out. But the rebuild is still manually kicked of. Not
> much work left to fully automate that work; knurd just needs to sit down
> and do it; pushing will stay manually in any case (for this a second
> signer in a non-EU-timezone would be ideal). But:
>
> - 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 :-/
I was originally thinking about this for kmods, but it would really work for 
any package: Bodhi now has RSS feeds for updates... It would probably be 
really easy to implement a tiny RSS reader in Python and have it compare the 
new updates to a list of packages that we define. If it hits a match, it 
triggers a rebuild the corresponding package in RPM Fusion.

> - handling of kmods for PAE and other special kernel variants could be
> easier; no big problem, but it needs to be easier in case -PAE kernels
> become default for i686 (see recent discussion on fedora-kernel-list)
>
> - 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 may be wrong, but if we do this I think it will be *very* popular... MP3 
playback & drivers are the most common "why isn't this default" complaints 
we see on FedoraForum. We'll need to get a few more mirrors and prepare for 
heavy bandwidth at release time.

> - should we have a page "this are the goals we want to archive with RPM
> Fusion" in the wiki somewhere? That afaics often helps to get people
> together and work towards realizing those goals
What do you think about this layout?
* /FoundingPrinciples: Extend this to include our goals & purpose
* /LicensingGuidelines: includes info about licensing & acceptable packages
* /Guidelines: RPM Fusion-specific guidelines, for example about kmods
* /Contributing: Our package submission process, links to the pages listed above

> = 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, I'm fully aware that such apps that do parts of this exist already.
> But some do stupid things and everyone could benefit from a sane app
> official app in RPM Fusion.
I've spoken to the author of Autonine/Autoten about this, I haven't taken a 
look at the script recently but iirc we could easily make those 
improvements, get it peer-reviewed and make it the official RPM Fusion 
enabler script.

> - Another small app (either tied into or separate of the install
> helper?) could things similar to the one jockey does in ubuntu (see
> https://launchpad.net/jockey and
> http://people.ubuntu.com/~pitti/screenshots/jockey/ ). Firewing1 is
> thinking about doing something like this already, which should make the
> "users don#t know which driver to choose" part easier
I have to take a better look later, but I don't think this will take very 
long either once we redo the distro-specific parts of the code to make it 
work with PackageKit. From there, Jockey should present the user with a list 
of drivers and a short message explaining which hardware it works with/FOSS 
drivers it disables and the users ticks off the ones they want.

> 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.
I agree - in a more generic sense, "just works" and good user experience is 
something that will require work on both the RPM Fusion and Fedora sides. 
There's some issues where we can't work together (proprietary stuff) but 
there's a lot of issues that could use some attention that would benefit 
both RPM Fusion and Fedora. There is a place where freedom and rapid 
innovation meet with good user experience. I think we should focus our 
efforts as much as possible so we get improvements on both projects!

> - switch to koji, bodhi, packagedb -> Xavier iirc is thinking about that
> and maybe doing some preparation for that; would be nice to switch, but
> no need to hurry, current setup works
That would be really great. A while back there was a discussion about 
creating a staging repo - we could implement part of that at least with koji 
scratch builds.

Stewart

[1] 
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-December/002934.html