Kevin's musings

This weekend seems to be the confluence of (at least) 3 great events:

1. bazcamp
2. Software freedom day
3. Talk like a pirate day

I intend to participate in all 3 if possible. Bazcamp is always a good time, should be heading out there tomorrow and hopefully help setup and grab the same spot we have had the last few years (it works out well). Good folks, food and place to hang out. Saturday is software freedom day and we should be hanging out at bazcamp and working on free software, what could be finer? Sunday we can set sail for home.

One of the new exciting features that was tenatively planned for Fedora 14 was systemd, a new cool init replacement. In tuesday’s FESCo meeting, it was decided to defer this feature until Fedora 15. There were problems in this process that I think we can learn from and try and do better with moving forward, but first; why did we want to defer it? (note: I am not speaking for anyone but myself here).

• Documentation was not really ready. It could possibly have been by F14 release, but it was a tricky subject: Do we mention systemctl for only those services that use it? There was no available GUI that would enable/disable native systemd services, so we would require systemctl command line, which doesn’t seem ideal.
• chkconfig/system-config-services has not been converted to deal with native systemd units.
• Packaging guidelines are not yet in place for systemd unit files. Granted that for most packages the answer is: “keep shipping your sysvinit script like normal”, but we HAVE converted some packages to native unit files. We need to be sure that we are setting them up right and that we don’t have to go back and re-do things when we have guidelines.
• A general feeling that we were rushing to get this in NOW NOW instead of feeling confident that we were ready to have millions of people use this.

Note that this is just defering this from being default in Fedora 14. It’s a great idea, and I am looking forward to it.

However, that said, mistakes were made, and I’d like to step up and appologise and see if we can learn to avoid them again:

• This should have been on the previous weeks FESCo meeting agenda. The systemd test day was going on then however, so I was waiting for that to have more data, then we just ran out of time. This was my fault. I think we should try and discuss such things even if we don’t have all the data. We could at least talk about the data we do have.
• The process for reverting a feature (enacting it’s fallback plan) should be enumerated fully. When can this happen by? Does it require a majority vote from FESCo? We need to add this to our Features Policy. When systemd was approved as a feature there were several people who stressed that we would review it and decide if it should be default later in the cycle. In this meeting we had a number of people who were ok with systemd in f14, but not 5 votes, which I read as lack of approval of this. I feel bad about this process because it seems like we were invinting it on the fly, which is bad.
• I could have communicated better with the feature owner. He was CC’ed on the meeting ticket, so should have known it was going to be discussed, but we should have tried to bring him into the discussion. I’m sorry.
• I filed the trac ticket on 2010-09-08 asking all FESCo members to vote on the issue. We had 3 people vote and add comments there from FESCo. We need a better way to deal with urgent non meeting items. Special Sessions? Subject line showing we need a vote? If you find yourself unable to vote in tickets or attend meetings, perhaps it’s time to step aside?

Now, some things that went Right here which I think should be called out:

• Lennart (The feature ower/author of systemd) has done an outstanding job of working on bugs and getting things working and fixed. I think systemd is on track to be very solid for Fedora 15.
• QA has done a great job of testing and finding issues and pointing out bugs.
• Bill Nottingham has done a great job of adjusting the initscripts/upstart/other packages for systemd as well as coming up with test plans for systemd.

Finally, I’d like to offer a personal appology to Lennart on how this process happened. Sorry. We will try and do better. Please make systemd good and solid for Fedora 15!

Just a quick note to let folks know about an IRC class that Mel Chua is going to be running in #fedora-classroom on irc.freenode.net tomorrow at 16:00 UTC.

See Mel’s post for more details.

I’m probibly going to do some more classes starting soon as well. They are great fun and a nice way to teach something you know. If you want to teach, have suggestions for classes or anything, please visit the Fedora IRC Classroom wiki page.

Last night was the local Blug meeting, and as always it was a good and thought provoking talk.

This month we had Bart Massey down from Portland talking about Linux history, where we are and where we need to go. He had some very interesting points and things we could look at doing in the linux community to try and keep things going the way that those of us who use and enjoy free software hope for.

Note: this is my thoughts based on his talk, credit goes to him, blame or inaccuracies are all my fault.

Currently, the Linux desktop is kind of in between a rock and a hard place: On one side, smartphones (iphone/android) and the other the web. If we don’t improve things and fast, we are going to basically get squished out of the desktop.This of course still leaves Linux on the server end, but that means that people who enjoy using a free desktop would have fewer and fewer options over time.

There are several areas ripe for improvement:

• We need to make it WAY easier to make desktop applications. Right now Bart pointed out that it’s a great deal easier to make smartphone or web apps. Why would you choose to try and make a gtk/qt app? He suggested going to some kind of better language, but their was no clear winner currently. Haskell and Java are better off than c/c++ in ease of use, but they have their share of issues too.
• The Linux infrastructure is old and confusing and nasty. There’s many years of history in lots of the stack, and it would be impossible to just redo it all at once. However, biting off chunks, reimplementing them and making the new thing work with the old setup seems possible here. I think this is what things like systemd are doing. Replacing old infrastructure with new. We need to do this more with areas that are old and failing.

I think what we can take away with this for Fedora is that we should be focusing on a number of areas:

1. Try and to the above to increase people using Fedora on the desktop (push fixes of infrastructure, make it easier to make more desktop applications).
2. Make sure Fedora gets known as a great testbed for the server side. Get more people who use RHEL testing and working on stuff in fedora to improve things down the road on the server side in RHEL.
3. Even though it’s not ideal in my mind, we should still position Fedora so it’s suited for running web applications (basically a webos/terminal) and a development env for smart phones and web applications.
4. Try and do the first three things while still allowing all the other various ‘niche’ users to use and enjoy Fedora.

Anyhow, I thought I would mention this given that the Fedora Board has been discussing Vision and other longer term plans. I think we should try and do what it takes to keep the desktop moving in a direction where it’s likely to expand, while still keeping track of the server and niche users (who we often seem to forget about).

A few folks were confused and dismayed to get an email today from bugzilla.redhat.com like:

“Some or all of your votes have been removed from bug NNNNN.

You had X votes on this bug, but X have been removed.

You have no more votes remaining on this bug.

Reason:

The rules for voting on this product has changed; you had

too many total votes, so all votes have been removed.

https://bugzilla.redhat.com/show_bug.cgi?id=NNNNN”

First, some background:

Bugzilla has “votes” on bugs. It allows each user to spend from their pool of votes and assign them to bugs that they like. I guess the idea is that highly voted bugs would show up as somehow more “important” and get more resources. We looked at generating a report on this to garner more resources for “important” bugs, but found that votes failed at this task for several reasons: They were hard to query, you could not tell how many people had voted, only total vote number, the vast majority of people didn’t see the voting interface so never voted, votes were never reported to maintainers in any way aside from the raw web interface, and others.

Additionally, some few people who did see the voting interface spent time and energy voting on bugs and asking others to do so, when in the end that did no measurable good aside from wasting their time. For these reasons, I asked the redhat.bugzilla.com folks to disable voting in the Fedora product.

Sadly, I was unaware that it would send emails to everyone who voted telling them (in a very negative sounding way) that their votes no longer counted. I’m sorry for any problems or negative energy this caused, I was just trying to save time and energy.

Additionally, I did hear of a valid use case for votes after the fact (but likely not enough for me to want to re-enable them): You can vote on bugs you care about, and use the voting interface to see progress on them (no need to CC yourself to a bug or spam it, you can silently see a group of bugs simply by voting on them).

So, I think this change was still for the best moving forward, and I would urge everyone who voted on a bug to go look at it and see what additional information could be added to it to move it to a resolution instead. FESCo has been looking at a way to see ‘very active’ bugs for a while now, please see: https://fedorahosted.org/fedora-engineering-services/ticket/24 if you have ideas or would like to help out.