Samstag, 25. Oktober 2008

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.

Sonntag, 12. Oktober 2008

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.

Samstag, 11. Oktober 2008

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.