Kevin's musings

It looks like I might have been able to convince enough of the right people and soon the rawhide repository file ( /etc/yum.repos.d/fedora-rawhide.repo ) will be moving to a subpackage of the fedora-release package.

Why? Far too many times in #fedora have we had folks that come in who have just enabled every installed repository, thinking this will give them more software choices. Unfortunately, once these people have installed packages from rawhide it’s very difficult or impossible for them to go back to packages from a stable Fedora release, and invariably they are forced to re-install. This makes them sad and upset, and makes those helping them sad too.

So, what does this mean? If you want to be using rawhide moving forward you will need to ‘yum install fedora-release-rawhide’ and enable it in the /etc/yum.repos.d/fedora-rawhide.repo file. If you install from a release once we have branched off rawhide for the next release, this package should not be installed by default, so you will have to install it to jump on the rawhide train.

Overall I think this is a good thing for our users and hopefully won’t inconvenience our rawhide folks too much.

As soon as the change lands I will be updating the fedora Rawhide wiki page. If folks know of any other docs that should be changed, please let me know.

As Christoph mentioned we are trying to open things up more and get more people involved in the Xfce SIG.

Toward that end we have created a new mailing list: here
as well as trying to figure out a good irc meeting time

Please join us if you use or have interest in Xfce in Fedora!

spoonfeeding:

noun
1.  feeding someone (as a baby) from a spoon
2.  teaching in an overly simplified way that discourages independent thought

I’ve been accused of this in the #fedora channel, so I thought I would throw out there my thoughts on this.

Overall I think it comes down to where you draw the line between ‘overly simplified’ and ‘helpfull’. Would you consider pointing someone to a specific link that addresses their problem spoonfeeding? How about if they run into problems following the steps from a link and want more help? Like many things it’s not a black and white line, it’s shades of grey or a spectrum from on one end to the other: “figure it out yourself and don’t bother me”, “http://lmgtfy.com/”, “Here’s a link that should help”, “You are stuck on step 5? ok, pastebin your exact output and let me try and break it down more for you’”, “Here’s a screencast showing the exact button to press”, “Let me explain how to plugin in and turn on the computer”, “Let me just login to your machine and do it for you”.

I personally think that Fedora support channels should at least go to the level of “Here’s a link that should help you” and likely to the “You are stuck on step 5? Let me try and break it down more for you” and don’t consider that spoonfeeding. My personal line is there before the ‘Here’s a screencast’ step, of course each person has their own line.

Of course if you find yourself in a Fedora support channel holding a spoon when you didn’t mean to be, it’s fine to tell the person you are helping that the spoon has to go back to the dishwasher and get someone else to continue to help them.

I’ve just finished another run of my sourcecheck script against all the Fedora devel packages.

What is that you might ask? It’s a pretty basic shell script that does:

• Operates over a full Fedora CVS checkout (which you can get from: http://cvs.fedoraproject.org/webfiles/)
• For each package it runs ‘spectool -g *.spec’ to fetch any Source files that have a URI.
• It checks any downloaded sources against the ‘sources’ file in CVS (which has a md5 checksum of the package sources from the lookaside cache
• It generates a basic log line for that package about what happened

So, why would I do this? Because it notices problems that we should fix. If a source is no longer available at the URI in our package it should be updated. If source has changed upstream without a new version, upstream maintainers should be notified and the issue corrected. If some maintainer checked in sources that don’t match the upstream project we should find out why. Imagine an end user looking at your spec file and trying to download sources for a package that they would like to contribute to, only to find that the URI is wrong.

This is the kind of thing that the AutoQA project should hopefully be able to take over at some point, but I’m happy to run my script until then. With AutoQA hopefully we can check this at spec/sources checkin time and stop the package update/import until the issue gets fixed. Until then we shall just have to clean things up as best we can.

So, if you maintain packages in Fedora, do take a minute to look for your name in http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20100105.txt and fix up the Source URI’s in any packages listed. It’s the right thing to do.

EDITED TO ADD: Sigh. Looks like my devel checkout was from an old checkout, so some/many of the results here will not be current. I am re-running it again against the current devel packages and should have an updated list in a few days. ;( Sorry for the trouble.