The Fedora Talk “activity day” was two full days packed with good discussions, learning more about Asterisk, sharing some good laughs, and getting a lot done.  Paul Frields did a great job coordinating the logistics for the event including our lodging and work place.  Paul picked a great location called Business Playce, a co-working office in Fredericksburg, Virginia.  The owner, Paul Delagrange was a fantastic host.  After seeing all our gear and noting that a bigger room was available, he “upgraded” us to a larger conference room on the spot.  This turned out well considering the tangle of cables,  phone hardware, and power cords we had assembled in the first hour.  Jeff Collie brought a nice speaker phone which we connected to Fedora Talk so others could call in.

The main purpose of this event was to get Asterisk gurus Jared Smith and Jeff Collie in the same room with the rest of us–Jon Stanley, Paul Frields, and Ian Weller, to nail down and implement Fedora Talk’s ability to record and stream conferences.  We also spent a fair amount of time increasing the depth and quality of Fedora Talk’s documentation which will hopefully be published soon at http://talk.fedoraproject.org.  A reminder that key links are in the navigation panel on the left even though they look like the regular sidebar links from the wiki.

We had great participation from all over the world.  Not only did six of us gather in Fredericksburg, Virginia, but a number of people called in from: Chicago, Brisbane Australia, Washington State, Utah, and other unknown locations.  We were able to provide this conference, free of charge for sixteen hours using the existing Fedora Talk set-up. On the phone we had help from Clint Savage in the way of setting up the IceCast streaming server, Mike McGrath answering Infrastructure questions, and Darren VanBuren and Clint working on documentation and creating screen shots.  Bruno Wolff also helped with a variety of things including testing of our new documentation.  Others helped too so if I missed you and forgot to mention you did send me an email or chime in on the comments.

I focused on the overall facilitation of the event by helping to guide the sprints and keep us focused on meeting our goals.  Along the way I learned how to configure my new (to me) used Grandstream phone, format documents for the Fedora website, and increase my git knowledge–it was funny and sad how many types I attempted to issue a git command by starting with cvs.  I also spent a lot of time updating the use cases and making sure we they were all documented and linked properly.  We discussed the possibility of taking another run at the unfinished tickets and documentation at FUDCon in Toronto (December 5-7, 2009).

One of the most interesting things I learned at this event was that Fedora is blazing a trail in the area of providing an open framework for managing the recording and streaming conferences with Asterisk.  As were getting started I asked Jared Smith (who also happens to work at Digium and would know better than anyone else) what other existing solutions we could use instead of “writing all this new stuff ourselves.”  Jared noted that while a lot of people have developed applications to manage call recordings and streaming, to his knowledge all of those applications have been developed privately and non of them are open source or freely available.

Specific things we accomplished:

• Thorough list of use cases for three types of Fedora Talk roles: Callers, Conference Facilitators, and Administrators
• Documentation for each of the use cases or URLs to open tickets
• Ability to record and/or stream conferences
• Call recording notifications
• Protoyped web application to control recorded or streamed conferences
• Comprehensive documentation for configuring and troubleshooting soft phones
• Jared enabled numerous bits of Asterisk functionality on the spot as result of simple “Can Asterisk do…?” questions.

Things to consider in the future:

• Identify specific tasks in advance that people on the phone can help with
• Have one person on the phone take the lead for helping coordinate tasks with other people on the phone and IRC or forming pairs to work on tasks

Key success ingredients:

• Being very clear, reasonable, and focused from the start about what we wanted to accomplish
• Lots of advanced planning, including mailing list discussions and IRC meetings
• Detailed use cases created before the event.  Use cases with people’s names made them more personal and fun.
• Having subject matter experts present–not on the phone, but in person to draw diagrams and explain complicated technical things in person and in real time
• Working in short sprints (45 minutes to an hour) to avoid getting too bogged down on a particular topic or going down needless rat holes
• Giving status to the rest of the team at the end of each sprint to explain what we had worked on or accomplished and what we learned.
• Working in pairs with a small group (six seemed to be a really good number).
• Being flexible about how we used our time while maintaining the same goals.  The sprints worked well for the first part of the first day.  At other times they did not fit the nature of the tasks we were working on.
• Outside of defined sprints, periodic check-ins with the group about progress and what we wanted to work on next–no less than once every 1.5 hours.
• Having lunch delivered to us so we could all eat and keep working–this added 1.5 hours to the day that would have otherwise been lost by going out, coming back, and starting up again.

For me the biggest win was the use cases we created in advance.  They were a critical filter to run new ideas through and keep us focused on what we wanted to accomplish and how we wanted to define “success” for the event.

Thanks again to all the people who participated and gave their time!

The long anticipated Fedora Talk Activity Day starts this Friday. If you have ideas or special needs for Fedora Talk, please update the use cases on the wiki.  See our overall plan for additional details.

We’ve been doing as much planning and organizing in advance as we can so that once we meet in person our time can be focused on implementing. I’ve been to several hackfests and FADs where a majority of the time was spent identifying and detailing things we need to fix in Fedora. While valuable, the implementation of those ideas usually takes several releases (a year or more) and some never quite get done. There are valid reasons for this I suppose, but having seen the pattern repeat itself I wanted this event to be different. My hope is that this FAD will be known for the things we got done and not so much the things we plan to do later.

For the past four weeks we have been planning and brainstorming on the infrastructure mailing list, creating wiki pages, and meeting on IRC. While not as fast as meeting in person, the overall results may be better because we’ve had time for our ideas and plans to ferment.  We got a lot of admin stuff out the way like figuring out what packages we need and what servers need to be rebuilt before we start.  Bruno Wolff also did a great write-up explaining how to setup Asterisk yourself.

One of the best ideas to come out of our planning meetings (thanks to Jeffery Ollie) was creating use cases to capture the needs of FedoraTalk users and administrators. These use cases form a natural link to open infrastructure tickets (RFEs) and documentation explaining how to execute each use case. By the end of the FAD we will have documentation for the use cases that are complete and open tickets for the use cases we intend to address in the future. This was another great discovery. A lot of great ideas from other Fedora events get lost in the sea of wiki pages, blog posts and and follow-up email discussions. Using this method, hopefully everything is in one place with a clear path to the documented implementation or a ticket reminding us we need to address it in the future.

I’m also hoping we can put to to use some things I recently learned about code sprinting at the Open Source Bridge conference–ironically the same place where the idea for the FedoraTalk FAD was born. I’m excited to see what kind of results we get from working in pairs and time boxing mini-sprints to 45 minutes.

Somewhere along the line the packages in rawhide (soon to be Fedora 12) became signed.  This is a good thing.  I don’t run a current rawhide box all the time so I’m probably the last one to know, but tonight when I tried to perform an update it kept stopping because it couldn’t verify the signatures on each package.

warning: rpmts_HdrFromFdno: Header V3 RSA/SHA256 signature: NOKEY, key ID 57bbccba


A couple of educated guesses later and everything works.  This important page has a list of the keys for each release.

Import the public key for Fedora 12:

# rpm --import https://fedoraproject.org/static/57BBCCBA.txt


Installing or updating packages should work fine now.

The other alternative to all this is that I did something goofy way back when resulting in a strange yum repo setup

One of the things I love about working in the Fedora Project is the opportunity to blog.  In the beginning I thought blogging was for other people.  Then I realized I needed a place to talk about the things I was working on.  Then it became more than that.

There is something to this “writing thing” that resonates with me and makes me want to become a better writer.  Along the way I’ve read a few different books about writing.  Currently I’m reading Writing Down the Bones by Nataile Goldberg.  Like most of the good books I’ve found on creativity and writing, they were recommended by Merlin Mann (see the reading list at the bottom).

Recently, Goldberg was talking about resistance and all the excuses we can come up with for not writing.  Her suggestion was to spend a little bit of time writing those things down before getting on with your writing.  Another good book about resistance is The War of Art.

I resist writing because I tell myself that nobody will read what I write because there is such an ocean of other stuff out there written by other people–why would anybody read what I have to say?  Or I tell myself that the blog posts I have in process or would like to write about are too complicated and will take too long to complete.  And by the time they are completed Fedora will have moved on and those thoughts won’t be relevant any more.

Sometimes it isn’t so much about resistance as it is the thoughts and ruminations about other things going on at work or at home.  A million questions fly in and out of my head as I try to “just write.” My conclusion is that sometimes you just have to come back to it.  It cannot be forced.  Other times brute force is just what is needed.

How do you know when you genuinely need a break or when you are just trying to talk your way out of having to do what you should be doing?

This is a little bit of a “fluff” post to satisfy those readers that are hitting my blog based on the title of a post in April 2009 (before the Fedora 12 Schedule was even finalized) who maybe disappointed by what they find there.  Fedora 12 is still under development.  Its planned release date is November 17,2009.  If you want a sneak peak, the Fedora 12 Beta will be released on October 20, 2009.  It will be available at Fedora’s pre-release download location.

Here are some important Fedora 12 links you might be looking for:

• Feature List
• Macro Schedule
• Micro Schedules

Or maybe you are looking for some ways to help out.  There is never a shortage of things to do in Fedora.  Helping out can mean working on something that is not your area of technical expertise, but makes everyone else’s lives easier.  Just today I helped call out the bugs for the Fedora 12 Beta Blocker review meeting.  I announced the meeting and helped facilitate the note taking and bug updating, but I can honestly say that none of my technical knowledge (or lack thereof) was used.

If you want to get involved, there are lots of choices in a variety of areas.

On the other hand if you just want to download the latest version of Fedora, that would be Fedora 11.

If you don’t want to download Fedora, but plan to be at LinuxCon next week (September 21-23, 2009) in lovely Portland, Oregon–visit the Fedora Booth and we’ll hook you up there!  Even if you already have Fedora, stop by and say hello.

In a previous post I mentioned my recent use of Freemind.  In this follow-up post I wanted to talk about what I’ve found and how I think we should move forward.  I couldn’t figure out a good way to attach the full map to this post so click on the links to see the full html, png, or pdf version.  The source file (right-click and save-as) is also available and can be read using the install steps in the previous post.

Several weeks ago at a release engineering meeting I volunteered to document our schedule methodology.  This fit with a project I had also started to document the guidelines for other parts of our release processes. Not surprisingly I found that we don’t have a well laid out map of our wiki pages on our release process.  Traipsing through all the wiki pages was tedious and not very fun, but in the end it was worth it.  Now I have a better idea what a good picture might look like. It might not be the final one we go with, but it is a start.

I’m not here to complain.  Instead I wanted to get the word out in case other people are interested in working on this too.  I want to make our release processes easy to understand and follow.  Each bubble in the map with an arrow inside is a hyperlink to an existing wiki page. We already have a lot of the information, but in some cases we speak in overly general terms and isn’t as clear or helpful as I think it can be.

One example is our release criteria page which speaks to blocker bugs (bugs that must be fixed before we ship), but isn’t specific about what release it applies to: Alpha, Beta, or Final.  This caused me to wonder if we have anything documenting about what our two test releases are for and what we hope to achieve from them.  That information would be good to know for writing the release criteria and blocker bug criteria.

The good news is that there are several people active in the Fedora Project that can answer these questions.  The not so great news from past experience is that each person has a slightly different answer.  I’m not advocating an iron clad policy that states the rules of our releases that can never be changed and must be adhered to at all times.  Instead I’m hoping that by writing all this stuff down it will help me and others to be clearer about what we want to accomplish together.  This information will also have a longer lifetime then our current oral tradition.

When I moved one step back from trying to determine what our test releases are for I bumped into the big unresolved discussion of “What is Fedora?”–not the right question, but I’ll get to that soon.

Smoothing out the schedule methodology page also backed me into the question of what we are trying to achieve from our releases in the first place.  And this led me to Fedora’s Overview and Objectives page.

Then I had an epiphany.

The Overview page started by explaining the difference between “Fedora” and “The Fedora Project.”  Several board members had been calling out this distinction in our meetings, but I hadn’t caught the importance of it.  It didn’t sink in until after I had corrected some of the inconsistencies and vagueness on the Objectives page itself.  The discussion that has been characterized as “What is Fedora” should more correctly be referred to as “What is the Fedora Project?”  We use the term “Fedora” too loosely.

The question we should be asking at a global level is “What is the Fedora Project and what does it want to be?” and breaking that down into smaller questions.  What the “Fedora Distribution is” is part of the answer to this question, but not the complete answer.  No wonder it has taken so long to discuss “What is Fedora?”

This led me to think that the Objectives pages could be boiled down to three or four core purposes.

Why only three ”core” purposes?

It is somewhat subjective, but the word ”core” generally means the center or the most important parts.  Fedora cannot have 15 central parts.  It can, but then it will never be excellent or great.  I know I am at odds with people I respect in the Fedora Project when I say this.  I don’t subscribe to the idea that the Fedora Project and the Fedora Distribution can be great without being focused and intentional.  We can’t measure our success or be “great” that way.  Instead we’ll end up doing a lot of things and being average at most of them.  Even once we decide what the core areas should be we will still have to make hard choices prioritizing our goals within each of them.

I’m suggesting that the three core purposes of the Fedora Project should be:

1) Building and releasing a free (as in Freedom or freely redistributable without limitations) distribution
2) Building communities
3) Furthering the science (methodologies) and practice of building communities

All the existing bullets on the Objectives page could fit into one of these categories

I have also started a thread on the fedora-advisory-board@redhat.com mailing list.  I would encourage everyone to share their additional thoughts and comments in that thread or make a blog post on this subject.

In the meantime I am continuing to work on filling out wiki the pages so that all of the bubbles in the mind map have red arrows and links to clear and specific wiki pages.

Ever since first reading about mind mapping I’ve used mind maps often to help clarify my thinking.  Bringing clarity to complicated and unclear situations is satisfying to me.  I like mapping out the complexities of a problem without explicitly trying to map out its solution.  Often the solution, or future state, becomes apparent simply by clearly mapping out the problem.

I am still not satisfied with the Board’s discussion on “What Is Fedora?” nor do I think we have closed out the topic that was first started in January 2009.  Several weeks ago when the Fedora 12 Alpha release slipped by a week I also volunteered to document our schedule methodology. As I started to search for existing wiki pages explaining our schedule methodology I came across several (outdated) wiki pages explaining our freeze and release engineering processes.  I fixed up some of those pages and kept going deeper and deeper into the complexities of our release processes.  It wasn’t the complexities of release processes so much as it was the twisted maze and circular path of wiki pages.  More on this in a separate post.

Being a long time fan of the mind mapping tool Kdissert I started several maps to try and track the logical flow of the wiki pages and our release methodology.  This worked fairly well, but I wanted to create a mind map that once published could also be used as a web page that could be navigated and “clickable.”

Somewhere along the line Kdissert became my mind mapping tool of choice.  It is light weight and no frills.  Initially the mechanics of creating new maps was a little confusing, but with a little practice creating a new map was effortless. Mind maps have helped me to diagram processes (limited use, but always good for a first cut), project plans, to-do lists, org charts, and many other things.  Needing a more robust mind mapping tool I went searching.

I goofed around a little with Semantik, the next generation of Kdissert.  It is not currently in Fedora, but Rex Deiter helped me build it.  I had tried Freemind a few times in the past, but was always draw back to Kdissert’s simplicity and speed.  In the past Freemind only ran with the Sun JRE which was a hassle to add to Fedora and overall performance was sluggish.

In my search I found a great article reviewing free mind mapping tools.  I was surprised how much the open source tools have matured since I last looked.  After reading a few more articles on Google and watching a good tutorial on YouTube I decided that Freemind was the way to go.  It has one of the richest feature sets of the programs I tried and a long history of continuous progress and development.  Freemind has the added advantage of being able to generate mind maps with embedded URLs that can still be clicked on in their published form.  Freemind maps can be exported in a variety of formats and imported to a variety of other mind mapping applications which I found in this interoperability graphic.

From the download page it appears that Freemind runs on any platform with Java.  Freemind is not in the Fedora repos though I believe there have been past attempts to package it which stalled during the package review process.  Historically I’ve found desktop Java applications to be really slow, but this isn’t the case with Freemind.  I’m guessing this has something to do with optimizations in Java since the last tried a Java application on the desktop.  To run Freemind on Fedora 11 perform the following:

1) Download the “binaries for any operating system“
2) Unzip the files into a new directory (otherwise your current directory will be polluted with an assortment of unorganized files)
$ unzip -d ~/freemind freemind-bin-max-0_8_1.zip
3) Run freemind
$ bash ~/freemind/freemind.sh

The same version runs fine on Red Hat Enterprise Linux 5.4 with five year old hardware.

I’m not the first to write about mind mapping in Fedora.  Clint Savage talked about some work he did last year mapping out the structure of the Fedora Project which I hope to borrow from.

I confess to having no idea what I’m doing, but I’ve got to say it tastes great and doesn’t dirty any pans.

I’ve been trying to eat less and eat healthier.  I’ve also been experimenting with eating a lighter meal in the middle of the day to see if I don’t get as sleepy in the afternoon.  Finally I was inspired by a cookbook my wife has been cooking from called Deceptively Delicious–the idea of sneaking healthy ingredients into regular food.

Here is the recipe for today’s smoothie based on whatever I found in the refrigerator–the only ingredients planned in advance (intentionally bought at the store) were the spinach, cottage cheese (super high in protein) and lemon.

These measurements are all guestimates:

• 2 cups of pure pineapple juice
• 5 generous handfuls of baby spinach leaves
• 3 generous scoops of cottage cheese
• 2 scoops of pure canned pumpkin
• 2 scoops of vanilla yogurt
• 8 large (see the picture) frozen strawberries–they are surprisingly good from Costco
• 1/2 lemon w/o the peel (usually I use a whole one, but I’m saving the other half for tomorrow)
• 1 banana

The best part of all is that it tastes better than something from Jamba Juice without the extra junk they add like ice cream to make it taste sweet.  Once all the ingredients get the “liquify” setting in our highly recommended Kitchen Aid blender–it tastes like a strawberry smoothie with a hint of pineapple and trace of cottage cheese.  The other ingredients, particularly the spinach cannot be tasted at all.  Today’s batch made about 32 ounces.  I’ll drink half for lunch and more later if I’m hungry and my family doesn’t get to it first.

Other recent incarnations have included random combinations of blueberries, blackberries, fresh ginger, purees of cauliflower or spinach, orange juice, tangerines, aloe vera juice, liquid trace minerals, fresh tomatoes, and other nutritious things I’ve forgotten.  It is a fun kind of trial and error.  After a few tries you get the hang of what forms a good base and what “extras” can send a good smoothie sideways.  In general it is hard to mess up.

What other winning combinations should I try?

Things are coming together for the next release of Fedora–Fedora 12!  The Fedora 12 Alpha will be publicly available next Tuesday, August 25, 2009.  Admittedly the term “Public Availability” sounds funny in Fedora… it isn’t as if the bits have been a huge secret for months.  Different in this release cycle is the change to two (previously three) test releases.  Fedora 12 will have Alpha and Beta test releases.

For other upcoming Fedora dates see the current schedule.  And don’t miss the action packed Fedora 12 Feature List.

The detailed team schedules have all the other dates you might be interested in.  Fedora 12 is the first release to have complete detailed schedules for every team working on the release.  Check them out if you are interested in what a particular team does or want to know more about what it takes to create a Fedora release.  These fantastic schedules were the result of detailed review meetings with each of the teams using the two tools in Fedora that I can’t say enough about: Gobby and FedoraTalk.  I’m hoping we can do all of our schedule reviews for Fedora 13 in person at the recently announced FUDCon in Toronto (December 5 to 7, 2009).

None of this scheduling goodness would be possible without TaskJuggler.  Like any tool it has its quirks, but one of things I love best about it is being able to code new tasks and make adjustments in a text editor.  This makes it easy to do version control, make quick changes, and compare different versions of the schedule.  Check out the Fedora 12 source directory to see for yourself.

I’m looking for a new LCD wide screen monitor in the 22″ range.  Contrary to the current industry trend, the biggest monitor possible is not what I’m looking for.  More real estate for distractions is not really what I need. The most important features to me are:

• vertical/height adjustment
• VGA and DVI input
• ability to switch between VGA and DVI by pressing a button (not having to delve into monitor menu each time)
• ~$300 USD
• a reasonable warranty
• I don’t care about USB connections on the monitor

I’m also tired of my stock Dell keyboard.  Since I spend so much time at the keyboard every day I think it is time for something better. Here is what I’m looking for:

• I like the feel of regular formed keyboard keys and the responsiveness of a good laptop keyboard
• not interested in the IBM clickity-clack thing
• ~$50 USD (realizing this could be completely unreasonable)
• PS/2 connection (so I can connect to legacy KVM and existing older boxes)

I’ve done a fair amount of searching about but there are so many choices and so many reviews, but so far nothing that looks like a good fit.

Any recommendations (manufacturer and model number) or links out there based on your experiences or what you have?  If so, I’d love to get your comments.