For several releases now, the Fedora QA team hosted retrospectives aimed at identifying process gaps and recommending corrective action. For those unfamiliar with the term retrospective, these events are sometimes referred to as lessons learned or, the morbidly named, post-mortem. We treat the retrospectives as living documents throughout a release. Noting the good, bad and ugly in an objective manner as issues surface. I’ve found recording issues as they happen paints a much more accurate picture, rather than trying to remember everything all at once after the product has been released declared GOLD. At the end of a release, we discuss, debate, propose recommendations and prioritize the work for the upcoming release.
We followed this process for several Fedora releases and most recently, with Fedora 13, created TRAC tickets to manage progress towards recommendations. There are still a few tickets remaining, but that’s okay. This is the first time we used TRAC to manage recommendations. I wouldn’t be surprised if we over estimated how much we could accomplish in the short time between releases. Of course, another way to look at this list is … if you’re interested in getting more involved with the Fedora QA team, review the tickets, grab one that looks interesting to you.
For Fedora 14, the retrospective process will continue. I started the wiki page a bit later than I prefer, but the page is up and ready for your ideas and suggestions … https://fedoraproject.org/wiki/Fedora_14_QA_Retrospective. To help the discussion, I’ll list my two most recent entries …
- Virtualization Test Day – Participation in the virtualization test day was low and not what we had hoped for. Why? What factors contributed to low attendance? What can we do to improve virtualization test day attendance in the future?
- Root cause analysis of RHBZ#638091 – Kernel panic during boot after updating to
glibc-2.12.90-13(see bodhi). The system would be fine until the
prelinkcommand ran, and then it would never boot and all commands would segfault on a running system. The issue was initially given positive proventester feedback as the system survived after a reboot. The feedback was later reverted after the testers system was unusable+unbootable after
prelinkhad run. The good news, the problem was discovered in updates-testing before it landed in updates. However, it would be good to have some documented test procedures for a subset of packages to guide proventesters
What other issues/ideas would you like to list on the Fedora 14 QA Retrospective? While you’re in the mood for feedback, please note that the QA team isn’t the only group interested in keeping track of issues. Check out John Poelstra’s thoughts on the Fedora 14 Schedule Retrospective, as well as Kevin Fenzi’s growing list of Updates lessons.