Where we are and where do we what to go?

[Thorsten Leemhuis]

thx for your comments (same to Hans and David btw)

On 25.01.2009 23:10, Stewart Adam wrote:
> On 1/25/09 1:33 PM, Thorsten Leemhuis wrote:
 > [...]
>> - 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.

The script from mschwendt might be the best; it (or a older version) 
reused parts from the push script (maybe only in older versions), which 
might make things easier. I'll talk to him in case Xavier doesn't want 
to handle it or worked on it.

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

I guess that's something else ;-)

http://fedoraproject.org/wiki/Features/YumMetalinks

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

+1

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

I'd make a few functions that switch all the important bits between 
Fedora and RPM Fusion free/nonfree with one command.

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

Well, we really need to be behind the idea -- it might not help that 
much if some packages are documented really good, while others are not 
documented at all.

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

But how to we get people to merge their repos into RPM Fusion? 
Especially the popular ones like Planet CCRMA?

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

+1 -- and to be *the* place we also need to have at least a unstable or 
playground repo, where those things can get done that we normally don't 
want to do. Without such a repo we force people to start their own. 
Reviews also need to be easy and quick.

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

Well, that's just one forum (albeit and important one) -- there are 
hundreds of forums and lists on the net and there is a lot of FUD 
floating around there. We can't stop that, but we might make it a whole 
lot less bad if we explain things better.

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

Like the one I started a few months ago? It wasn't used much yet
http://rpmfusion.org/News

And the idea with the planet got stuck as well :-/

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

Sounds good. Many Thx!

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

That's not the problem I was talking about (and there are better ways 
then koji ;-) ). Look again at
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html
to understand the problem.

And what you outline is not needed that badly afaics.

> [...]
>> = 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

http://www.dnmouse.org/autoten.html

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

Before that it needs to become a whole lot easier to use and ask only 
important questions by default (mainly: Do you want nonfree or not?)

And just like we don't ship packages that could be in Fedora I don't 
want our installer to do things that should be done in Fedora. "Enabling 
sudo" or "Gnome art next gen" for example (both examples taken from 
http://www.dnmouse.org/autoten.html ).

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

The staging repo I suggested a few weeks ago can easily be realized with 
plague as well (but I don't understand what scratch builds have to do 
with it...).

CU
knurd