Sonntag, 18. Januar 2009

Communication is important

Short version: More and more decisions in Fedora are done on IRC and in other places you have to be aware of; that itself would be no problem if the mailing lists would stay in the loop to make sure people cat raise their option before something is decided. But that's often not the case. The Fedora Project needs to improve here, as proper communication between contributors and those that make the decisions is a key factor for a community project.

Long version: Cut'n'pasted below is a part from a post that some time ago was send to some random fedora mailing list by someone that's quite important in Fedora:
I get the fact that you resent being in a timezone and location that
makes it difficult for you to participate in higher bandwidth forms of
communication (irc, phone, face to face). I can't help that. However
I'm not about to force the entire Fedora project slow to a crawl just so
that every thought, comment, discussion, fart, whatever happens via a
public email. That's just ridiculous. People will continue to talk on
IRC, will continue to chat via IM, will continue to talk on phones, and
will even *shock* talk in person! Ideas, proposals, and even a decision
or two, depending on the group, will be made in these ways. Deal with
it.
Statements like this are one of the reasons why I'm not as active in Fedora anymore as I was two or three years ago.

Sure, the one that wrote above para made a lot of good points. Face-to-face or IRC meetings are important and often help a lot to drive things forward. And we all afaics don't want a totally bureaucracy Fedora with hundreds of rules that express how decisions or other things have to be done; I actually tend to say we actually have way to many rules in some places already and need to get rid of a few (but that's a different topic).

But in the end above para sounded to me: be on FUDCon, IRC, or right hallway at a specific time on a specific place on earth or you have no chance to influence things. It might not have been meant that way, but that's what my mind made out of when reading it. Partly that's because I got the impression that more and more things in Fedora actually work in a "be there at the right time and place if you want to get heard"-way. Obviously that's bad for a lot of contributors due to time zone differences, job, vacation, or other real life issues getting in the way; which, obviously again, is bad for a community project that has contributors from places spread all over the world, as it excludes some contributors from getting involved or from influencing decisions.

That's why mailing lists (or a similar form of time-zone-independent communication) IMHO are very important for community projects with lots of contributors. But Fedora seems to move more and more things away from the public lists to other places -- especially IRC is used more and more desperate that we know there are people that don't want or can't join IRC.

Moving things to IRC wouldn't be such a big problem if important things that come up for decision in IRC or other places get announced properly 2 or 3 days beforehand on the lists. But that's often not the case, hence people that can't make the meetings get no real chance to see what coming up -- hence they can't share their options before something is up for vote. But that's IMHO a very very important factor for a community project, as contributors want to feel "heard" and have a chance to influence stuff, as that makes them feel as part of the project (and not like a citizen of a state where you can elect the decision makers every few months or year) -- even if the outcome in the end is not what the contributor wanted initially, as everyone knows (or at least should) that you can't get everything you want every time (a pony anyone?).

What makes things even worse: Now and then there are insufficient summaries from Fedora IRC meetings; the board is the big exception here while rel-eng often is not writing a summary at all. Sure, writing those summaries is a boring task -- I know that, as I had to write a lot of them for FESCo and the EPEL Steering Committee in the old days. But it's worth it, as a quick summary (even if it misses some details) is way easier to read then a log from a IRC meeting; that helps people to know what's up which again gives them the important feeling that they are part of the project. Not even trying to write summaries IMHO is a bit like top-posting and not removing unnecessary parts when replying to a mails on a mailing list: it might be easier and quicker for you, but a lot harder and time consuming for all those out there that want to know what's up. It shows disrespect for the community.

Time and place independent communication also is not only important for IRC but also for conferences. That why I'd like to say "Thanks" to Karsten Wade aka quaid for his recent blog post "Where are your FUDCon session notes?". And also thanks to all those that put videos from the recent FUDCon sessions online. Albeit those OTOH are a bit like IRC meetings without summaries -- watching them just like reading IRC meeting logs takes a lot of time and at least for me often has a bad "benefit per time ratio" :-/ . But as I said earlier: You can't always get what you want and this is a area where that's the case ;-)

Samstag, 13. Dezember 2008

Fedora and support for new hardware

As some people will know: At work I have to deal with brand new hardware (especially CPUs, graphic cards, motherboards, printers, scanners) a lot. One of the two(¹) main reasons why I (and some of my colleagues) use Fedora when it comes to test new hardware for compatibility with linux: Stable Fedora releases regularly get new versions of kernel, sane, xorg-drv-*, and some other hardware-related software as regular update during their lifetime; that improves support for hardware (and especially new hardware) a whole lot over time, as those updates to new versions also bring lots of new and updated drivers. OpenSuse or Ubuntu don't do things like that -- you are either forced to run the devel tree to get new drivers or you have to wait six to eight months till the next release comes out.

But when I took a closer look at Fedora 10 I really was disappointed when I noticed that both gutenprint and hplip (likely the two most important packages with printer drivers) were far from up2date -- especially for gutenprint that sucked, as gutenprint 5.2.1 had brought support for a whole variety of new printers one month before Fedora 10 came out.

But that won't matter much anymore soon: Tim Waugh(²), prepared updates for Fedora 10 that bring gutenprint and hplip up to the latest upstream version. Many thanks for your work twaught!

Ohh, and while at it also many thx to davej, cebbert, kylem, ajax, nphilipp and all the other package maintainers that update packages like kernel, xorg-drv-*, sane, and others to the latest upstream versions now and then in stable releases. I (and I guess lot of people that buy new hardware now and then) really appreciate your work!

(¹) the other: Fedora most of the time doesn't contain drivers or patches that are not yet upstream or on the way upstream. So if it works in Fedora then it most of the time should work on other dists that have the same or a higher version of software like kernel, xorg-drv*, ...

(²) he seems to be a bit more cautiously than some of the Fedora packagers (not sure if that's good or bad) -- the maintainers of packages like kernel or openoffice.org for example had incorporated beta released of their software before the feature freeze and updated that to the final later. Hence that software was up2date when F10 came out; but that is likely a whole lot of work (which otoh helps both Fedora and upstream to get the software in better shape)

Dienstag, 2. Dezember 2008

New toy

We not only got a new cat -- we (or, to be precise: my girlfriend) also got a netbook. A Samsung NC10 in white:
The Fedora 10 installed just fine -- no problems at all. Dmesg, lspci:
00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GME Express Memory Controller Hub [8086:27ac] (rev 03)
Kernel driver in use: agpgart-intel
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae] (rev 03)
00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03)
00:1b.0 Audio device [0403]: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8] (rev 02)
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel
00:1c.0 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 [8086:27d0] (rev 02)
Kernel driver in use: pcieport-driver
00:1c.2 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 [8086:27d4] (rev 02)
Kernel driver in use: pcieport-driver
00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8] (rev 02)
Kernel driver in use: uhci_hcd
00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9] (rev 02)
Kernel driver in use: uhci_hcd
00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca] (rev 02)
Kernel driver in use: uhci_hcd
00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb] (rev 02)
Kernel driver in use: uhci_hcd
00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc] (rev 02)
Kernel driver in use: ehci_hcd
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev e2)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 02)
Kernel modules: iTCO_wdt, intel-rng
00:1f.2 IDE interface [0101]: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller [8086:27c4] (rev 02)
Kernel driver in use: ata_piix
00:1f.3 SMBus [0c05]: Intel Corporation 82801G (ICH7 Family) SMBus Controller [8086:27da] (rev 02)
Kernel driver in use: i801_smbus
Kernel modules: i2c-i801
02:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter [168c:001c] (rev 01)
Kernel driver in use: ath5k_pci
Kernel modules: ath5k
03:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8040 PCI-E Fast Ethernet Controller [11ab:4354] (rev 13)
Kernel driver in use: sky2
Kernel modules: sky2
I didn't test everything yet, but suspend, hibernate and wifi worked out of the the box. Regulating the display brightness does not work using the function keys -- but it works using the gnome-applet.

Seems the wifi-LED does not work; and when I once disabled wifi using the hotkeys I could only get it to work again by restarting the system -- not sure, maybe it was just a hickup or something like that. I'll investigate further over the next few days.

Montag, 1. Dezember 2008

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

Sonntag, 30. November 2008

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

Dienstag, 25. November 2008

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:

Montag, 10. November 2008

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.