Poelcat

Thank you Paul!

I am honored to accept an appointed seat on the Fedora Board and looking forward to the year ahead.

Having served as the secretary to the Fedora board for roughly the past two years I’ve recorded a lot of meetings and tracked a lot of discussions–a majority of that time saying very little except to clarify the issues being discussed for the minutes or nudging the discussion back to the topic at hand.  This has served as a great unintended education into how Fedora functions and what issues are important to it.  I’m looking forward to putting this experience to great to use.

I am also looking forward to helping lead Fedora into the future.  At a recent Portland State University (PSU) project management class, Paul Spindel, an excellent instructor and facilitator, encouraged us to think about our responsibilities and to ask ourselves how much we are “managing” versus “leading.”  Managing is thought of in terms of “managing” day-to-day operations and keeping things from running off the tracks.  Managing is a very necessary thing to do, but it is different from leading.  Leading is an activity that seeks to take things to the next level, to “lead” a project or organization forward to new and greater things.

When we think of leaders, we recall times of turbulence, conflict, innovation, and change.  When we think of managers, we recall times of stability, harmony, maintenance and constancy.  We need leaders and we need managers.  Both are essential to making social systems work.  But each plays distinctively different roles.  And the unique role of the leader is to take us on journeys to places we have never been before.

–Exerpt from The Leadership Challenge by Kouzes.

I think this is a fantastic quote and how I hope to contribute as a leader to the Fedora Board. This quote was in our course book with attribution, but so far I haven’t been able to find the exact page in “The Leadership Challenge” by Kouzes & Posner (4th edition).  So far it is a good book.

I’ve been participating remotely in the Fedora Activity Day (FAD)  in Raleigh, NC.  The sound quality over Fedora Talk is extremely good calling in with a regular phone (with the exception of other people forgetting to mute), though it is harder to hear some of people not so close to the phone.  The combination of gobby, IRC and the live audio is almost as good as being their in person.  So big thanks all the people that made those things happen!

I think I understand the purpose of this FAD better now and it has clarified for me the problems that we have with rawhide and the test releases:

• We need to freeze rawhide to put out our test and final releases
• When rawhide is frozen it makes it harder for developers to do their work.
• The test releases need to go out as soon as possible because if released too late they are obsoleted by all the new changes added to rawhide.  Because of this we can’t test the test releases too long before making them available because too much else will have changed if we take too long to test it.
• We can’t publicly test the release candidates because of the short amount of time to create, test, and stage them.  This is due to the size of the content and not wanting to delay rawhide any more than is necessary.

In terms of formal testing for our upcoming releases, we create installable images (test releases) for wider community testing.  Opinions vary on the value of these releases because once installed, testers are encouraged to update to the latest rawhide packages–sometimes upwards of hundreds of packages.  If this is the case is the return on investment for resources invested to create, qualify, and distribute the test releases worth it?  We definitely see an increased interest on the mailing lists and more bugs being filed, yet we do not have any hard data to definitively say. For Fedora 12, the Alpha release was dropped for this reason, combined with a shorter schedule to get back to our standard “Halloween/May Day” six month schedule.

Seth Vidal said it best, “Some people want to check a package into a repo and others want to build a distro.”  I think there are probably people that want to do both too.

Even with freezes, rawhide changes a lot.  Eventually the changes in rawhide do stop, but not until close to the end.  During Fedora 11 I ran repodiff every day comparing the current day of rawhide to the previous day.  Some interesting results I found were:

• 1,940 package changes between Beta Freeze and Final Freeze
• 620 packages changes between Final Freeze and the first RC compose
• 90 packages changes between the first RC Compose and GA

Note: some of these changes could have been the same package being rebuilt multiple times.

I have always been sceptical of the wisdom of considering rawhide our primary testing vehicle.  From a formal QA perspective this is the nightmare of all testing scenarios–the product you are trying to test never stops changing.  To Fedora’s credit our releases have been pretty solid (with occasional exceptions) anyway which continues to amaze me.  I still secretly wonder how solid and polished our releases could be if we took a more traditional approach to the allowed amount of change.  I think the constant changes do contribute to our pattern of slipping test releases and final release dates by a week or two.

Some people argue that a week or two late in the world of software releases isn’t that big of a deal and maybe it isn’t.  Traditional software projects often have a much longer development duration and a week or two late for a project that took a year or more to complete isn’t that big of a deal.  For a project that seeks to release every six months, a week or two late is a bigger percentage slip compared to the total development time.  For a “time based release”– it also shortens the time allotted to the next release.

The proposal (as I understand it) from the FAD would allow rawhide to continue without freezes–removing the resulting holdups to developers.  It would also specify a process to examine the changes added to the release under development after a certain point in the development cycle.  Read all about it at https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal.

One of the best things to come out of the development cycle for Fedora 11 is a continuous stream of test days.  James Laska with the help of Adam Williamson shows up every week to lead the charge–sometimes twice in the same week.

Before Fedora 10 there were no official test days as we know them now.  Fedora 10 had a series of test days and when Fedora 11 came along they became the standard.  It always makes me smile when I read somewhere or hear someone say “we really need to have a test day for that.”  A year ago no would have been familiar with that term.  James just showed up and started arranging weekly test days and now the rest is history.  Just because James and Adam organize them doesn’t mean they don’t continue to need more help.

Another great thing that has happened during the Fedora 11 development cycle is live images created specifically for the test day–with the added bonus that are known to work good enough to install or run live.  I spent most of the test days during the Fedora 10 cycle just trying to get rawhide to install or update to a workable system.  This part of the ”rawhide process” is still broken–not having a canonical place to easily find out in advance whether rawhide is “good” that day or not.

What if someone else volunteered to be responsible for creating and making the live image available on test day?  The feature list for each new release continues to grow and there is no way that this ”core duo” can continue to do all the heavy lifting.  Talking to James it sounds like running two test days a week consumes a lot time more time than just those two days which is a lot of time itself.

So what does this mean?

A few ideas I have:

• Link to each test day page from the feature page
• What if during the planning phase of a release the QA team selected in advance which test days they would host and run?
• Create a test day process that is more scalable and doesn’t depend solely on James and Adam to make them happen
• What if there was a framework, kind of like the feature page process, where other non-regular QA team participants could propose and hold their own test days?

Test days beyond the ones owned by QA would be volunteer driven–much like the feature process.  The idea that if you show up to own and do the work it is yours.  And if you don’t prepare for and host the test day it doesn’t happen.

The QA team could still help advertise and schedule the test days, but the test case development, wiki page creation, image generation, etc. would be done by the people desiring the test day.  Which could mean anyone interested in Fedora.

It is definitely possible.  Look at this fantastic test day page for KVM created by virtualization developer Mark McLoughlin.  You can join in the fun and participate on May 7, 2009.  This page even tells you what you need to do before the test day starts, how many people are needed, and what kind of time commitment is required.  This clicks with the way I think and am motivated.

I am much more likely to commit time to something that looks well planned and sets out to honor my time and effort because the time I can commit is limited.  Most people with limited time are looking for a tangible practical place to plug in and help.  Well written test day pages provide that and help Fedora grow beyond where it is today.