Read the same paragraphs every half year?

I really wanted to read the Fedora 10 Release Notes, but when I did I quickly got distracted. Later I asked myself why and gave it a second try with the goal: watch closely why you got distracted.

I first noticed that I had missed the brief overview at the bottom of the first page. I simply had hit "Next" on the top of the first page, as I expected it to be just the index, like it's iirc is in so many multiple-page howtos -- abs is just a random example here.

I further noticed that the text it a bit hard to read, as all the links are written in plain text within the text -- so you have to skip them with the eyes when you try to read continuously. To stress this a bit more compare yourself, which to you think is quicker and easier to read:

• Features for Fedora 10 are tracked on the feature list page: http://www.fedoraproject.org/wiki/Releases/10/FeatureList

• Features for Fedora 10 are tracked on the feature list page.

I then got to section 2.1 and read: "Anaconda is the name of the Fedora installer. This section outlines issues related to Anaconda and installing Fedora 10." I don't like the bold writing -- I find is distracting. But I know, some people like that. The real problem is something else and gets even more obvious in the whole section 2.1.1: Most if not all existing Fedora users know all of that already.

And that IMHO is the big problem of the whole release notes. Sure, these information are important for new Fedora users and hence they need to be written somewhere. But these information are just boring for all the existing Fedora users out there. The new information between all the old and well know stuff on the other hand is very important to existing Fedora users -- we want them to read it (which most do not afaics). Thus I'm really wondering if we should provide a second version of the release notes that only provides information that are really new -- then users that come from the previous release only have to read that document, which like is a lot shorter.

I'm not even sure how hard it would be to create that section release note set -- maybe running a diff over the old and new version, cut'n'past the relevant paragraphs where something important changed and put them into one document.

P.S.: Another thing that I dislike in the Fedora 10 Release Notes: Why isn't there a single-page version online that would make searching something a whole lot easier. Example: I knew there was a paragraph in the release notes regarding the flash-plugin. Hence i browsed to the Fedora 10 Release Notes Index, typed "/flash" in Firefox to find it, but failed. I tried some other keywords like "plugin" and failed as well. After a while I gave up and asked Google with the search term "flash-plugin site:http://docs.fedoraproject.org/release-notes/f10/en_US/" -- then I quickly found what I was looking for. Works, but only is you know how to use Google properly :-/

Number 3: Ginger

Three and a half years ago Linus & Lucy moved in. Now they got someone to play with: Ginger




Welcome Ginger, hope you'll like it. Ohh, and Ginger, if you read this: Please stop playing on the edge of the floor above the stairs! You can fall down there easily (remember: you were close to falling down there a few times already!) and chances are big that you'll break your neck if you do.

P.S.: We considered to stick to names from Peanuts. Pig-Pen would have fit Gingers look, but well, she's (a) a girl and (b) that not really a good name for a cat. Hopefully Ginger sticks with us -- the original Ginger always tried to escape from "home".

Enable RPM Fusion during Fedora install

To all those that install the brand new Fedora 10: If you enable the RPM Fusion online repositories during install you'll in F10 and later will automatically get some of the packages installed that RPM Fusion provides. Which packages? Well, that depends on what software you choose; if you for example stick to GNOME you'll get gnome-mplayer and some gstreamer plugins by default.



For details how to use RPM Fusion during install please take a look at the documentation in the RPM Fusion wiki. It also holds some information's how to enable RPM Fusion after installing Fedora.

See also:

• RPM Fusion free and nonfree repositories for Fedora 10 (Cambridge) now available on fedora-announce-list

RPM Fusion for EL in the early testing stage

A lot of people in the past asked for a „Livna for RHEL/CentOS“. There were rough plans to create one, but they got dropped immediately when the idea to merge Livna with other 3rd party repositories for Fedora came up. That lead to RPM Fusion being formed,which was announced one week ago.

Sharp eyes will have noticed that the announcement did not contain any information's regarding support for EL. That was on purpose – we focused on getting RPM Fusion running, hence the EL branch (which was planed right from the start) did not get as much love as the Fedora branch. But the EL branch is in the works and some of the most important RPM Fusion packages have been built for EL already. Xine and xine-lib-extras-freeworld for example are available in the testing repository already; the AMD and Nvidia drivers are still missing, just like mplayer and vlc. But all of them should hopefully get into the repositories over the next few weeks.

You can already help testing the RPM Fusion packages for EL repositories by enabling it with this command:

rpm -ivh http://download1.rpmfusion.org/free/el/updates/testing/5/x86_64/rpmfusion-free-release-5-0.1.noarch.rpm http://download1.rpmfusion.org/nonfree/el/updates/testing/5/x86_64/rpmfusion-nonfree-release-5-0.1.noarch.rpm

Some of the RPM Fusion packages for EL require bits from EPEL, hence it's necessary that you have EPEL configured and enabled as well – just like you had to enable Fedora Extras to use Livna in the Fedora Core days. Just remember that the RPM Fusion for EL repositories are still in the early stages. Also not that you for now need to enable epel-testing, as some of the RPM Fusion packages depend on packages that are currently in epel-testing. That requirement should hopefully vanish with the next testing -> stable move in EPEL. The RPM Fusion for EL repositories of course don't replace and packages from EL or EPEL.

Note that not all RPM Fusion contributors have interest in building their packages for EL (just like not all Fedora contributors participate in EPEL). Hence we could need some help and people with rpm packaging skills that help getting the RPM Fusion repositories for EL filled and maintained. If you are interested contact me in private or (preferred) join the mailing list and just start to help.

Second step of the transition from Livna to RPM Fusion: Moving F8 and F9 testing users over

After enabling the RPM Fusion repositories for users of Livna devel a few weeks ago we now do the next step to move livna users over to RPM Fusion: Enable RPM Fusion for those F8 and F9 users that have livna's testing repos enabled.

The way to do that is round about the same as in the devel branch earlier: I added the rpmfusion-release packages for RPM Fusion's free and nonfree repos to the livna repo for F8 and F9; afterwards I built new livna-release for F8 and F9 that went into livna-testing; those two livna-release packages track the two rpmfusion-release packages in with a hard dep. That way all users that installed livna properly (e.g. by installing the livna-release package) and enabled the testing repos will now get RPM Fusion enabled automatically.

Note, nearly all of livna's packages have been imported and build for RPM Fusion, but a few are still missing. So you should leave livna repos enabled for now if you want everything. Once all the packages have a new home we'll let the rpmfusion-nonfree-release package obsolete livna-release.

The plan is to move regular livna users of F8 and F9 over to RPM Fusion with the same trick sooner or later. But some things in RPM Fusion need to get brought in shape before we start considering that. But if you want you can already help by using and testing RPM Fusion for F8 and F9 by running this command:

rpm -ivh \
http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm \
http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

It's even easier if you have livna enabled already:

yum install rpmfusion-free-release rpmfusion-nonfree-release

Please spread the news, to make sure all the docs in the internet get updated! tia!

P.S.: Just a reminder while at it: Some of you might have noticed already, the livna mailing lists (like freeworld{,-graphics}@livna.org) are dead since a few weeks; the hard disk in Anvil's mailman host died afaik (I don't know more details; sorry). But Livna will be superseded by RPM Fusion soon anyway, so simply use the RPM Fusion mailing lists from now on. They should serve well for the remaining time, as all the livna contributors should be subscribed there as well. Sorry for the trouble.

First steps of the transition from Livna to RPM Fusion begins soon

Over the next few days (likely on Tuesday evening CEST) we'll begin to slowly move users from Livna over to RPM Fusion by activating the RPM Fusion free and nonfree rawhide repos for livna-devel users.

The plan to realize that transition is quite simple: We'll add the rpmfusion-release packages for RPM Fusion's free and nonfree rawhide repos to the livna-devel repo; then we'll build a new livna-release package that tracks those two rpmfusion-release packages in with a hard dep. That way all users that installed livna properly (e.g. by installing the livna-release package) will get RPM Fusion enabled automatically. Yum/PK will download a big bunch of updates during the next update, as all the packages were build anew for RPM Fusion; but rawhide users are likely used to that, so this should hopefully not be a big problem ;-)

Note, nearly all of livna's packages have been imported and build for RPM Fusion, but a few are still missing. So you should leave livna-devel enabled for now if you want everything. Once all the packages have a new home we'll let the rpmfusion-nonfree-release package obsolete livna-release. But please note that all the packages that have been imported to RPM Fusion will not be updated anymore in livna-devel from now on, to save work for repo and package maintainers!

The plan is to move livna users of F8 and F9 over to RPM Fusion with the same trick sooner or later. But some things in RPM Fusion need to get brought in shape before we start considering that. But if you want you can already help by using and testing RPM Fusion for F8 and F9 by running this command:

rpm -ivh \
http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm \
http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

And if you installed a Fedora Beta or Rawhide then from now on use the following command to enable RPM Fusion for rawhide:

rpm -ivh \
http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-rawhide.noarch.rpm \
http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-rawhide.noarch.rpm

Please spread the news, to make sure all the docs in the internet get updated! tia!

P.S.: Some of you might have noticed already, the livna mailing lists (like freeworld{,-graphics}@livna.org) are dead since a few weeks; the hard disk in Anvil's mailman host died afaik (I don't know more details; sorry). But Livna will be superseded by RPM Fusion soon anyway, so simply use the RPM Fusion mailing lists from now on. They should serve well for the remaining time, as all the livna contributors should be subscribed there as well. Sorry for the trouble.

Popular things are often not the right thing to do

No, this has nothing to do with the presidential elections in the US; but yes, it's about politics. To quote from a mail send by dwmw2 to fedora-devel:

I propose that each FESCo member should try to work on at least one
package review per week. Each week at the FESCo meeting, we'll ask
members which reviews they've worked on in the past week.

Nice idea, but for me that sounds like a pre-election promise to lower taxes or like big and rich politicians handling out food in a soup kitchen or a: It will help a few people and gives good press because it's popular, but it doesn't solve the underlying problem at all. In fact it's even worse, because time gets wasted instead of solving the underlying or other problems (that might be bigger or smaller).

Verbose:

Sure, putting pressure on FESCo members to do reviews will force them to face some of the problems in the review process. That might result in some small improvements to the review process that might make things easier in the long term (but for that to really become true we also would need to have the same "should try [...] at least one package review per week" suggestion for members of the Fedora Packaging Committee as well); and of course the review queue gets a tiny fraction shorter due to the reviews that get done. But the time imho would be *way* better spend if some FESCo members would directly work on improving the review process with people that are doing lots of reviews (hello tibbs), because only that will improve the situation in the end (if done properly) and solve the problem (as far as it's possible to solve).

Ideas for making things easier and better are there; they are afaics well known among contributors and the different committees that are responsible. Just nobody is working on them:

* improve rpmlint and other tools to automate more of the checks to less the burden on the reviewer

* make review exchanges easier; maybe even force/guide/direct people a little bit to do exchange reviews (e.g. a little bit like, but not as strict as "if you want to get your packages reviewed you have to review a package from somebody else first")

* look more actively for new sponsors and be less strict when choosing them (like it has been in the past); we all make errors -- it's the ability to learn from them and to fix the errors once they got made

* be less strict with sponsoring people like it was in the early Fedora Extras days in 2005. We can do that now that new packagers don't get access each and every package in CVS

* add one more level between new packagers and sponsors; soon-to be sponsors there could work together with new packagers and keep an closer eye on them; by that they could get work of the real sponsor and show their ability to become a real sponsor sooner or later

* let FESCo and the Fedora Packaging Committee work together to make review and packaging guidelines easier to understand. We have done that two times in the past iirc (once in the fedora.us days and the last time it iirc mainly was spot's work with some help from mschwendt, scop and some others in the early FESCo days before the FPC existed). I tend to say it's overdue to do it again. Guidelines for corner cases in that process should get moved to special add-on documents or sections that are hidden by default. That will make the main things easier to understand and remember. Otherwise we soon have guidelines that will look like a code of law/statute book that nobody really understands as knows, as they are long and quite hard to read. Maybe splitting the guidelines might make sense as well: a "this is how it works in general" could be the quick ans easy start; a "here is how it works in detail" could serve as reference doc wher you have to look for the details and special treatments when it comes to perl/python/mono/java/...

* there are likely more ideas floating around...

And note, package reviews are just a fraction of the the area that FESCo is responsible for. So in the end instead of wasting time in each FESCo meeting with questions like "which reviews did you work on over the past week" it would imho be way better to ask "what did you do over the past week to make Fedora (the distribution and the project) a better place for contributors and users". That would also help to answer the "whom to vote for in the next election" question a lot.