Fedora 14 Schedule Retrospective

Background

Largely inspired by the success Fedora 13 QA Retrospecitve and the benefit of capturing data from ideas and events when they happen, this page is for tracking Fedora 14 schedule successes and mis-steps. It's goal is iteratively track and refine our process of testing and releasing Fedora 14 on time.

Any Fedora team member or community observer is welcome to add information here.

Successes

Task	Date	What was successful?	How to Repeat It?
Pre-Alpha Rawhide Acceptance Test Plan #1	2010-07-12	Anaconda traces back on install. The success here is that we discovered this problem four weeks before the Alpha Compose	Keep doing what we are doing
Pre-Alpha blocker bug meetings	2010-07-24	Meetings are happening each week and people are referencing the release criteria in the bugs--this is helping to save time at the review meetings	Continue to encourage people to become familiar with the release criteria and refer to it

Could Have Been Better

Task	Date	What Happened?	What To Do Differently Next Time?
Create Installable Images for QA testing #1	2010-07-08	Not ready until 2010-07-12 Installer lead was out during week, backup built anaconda-14.10-1.fc14 and pykickstart-1.76-1.fc14 in rawhide on 2010-07-08 Release Engineering lead was on out on 2010-07-09 Koji Outage 2010-07-10 to 2010-07-11	Verify that desired anaconda version is available the day before compose Coordinate with installer lead several weeks prior Create a checklist of reminders and dependencies that should be confirmed prior to the compose date? Send a reminder to devel-announce to have packages in rawhide for upcoming compose Build up the Release Engineering team so that alternate team members can compose releases
Create Installable Images for QA testing #3	2010-07-22	Not ready until 2010-07-23 glibc change for minimal kernel delayed getting rawhide composed	Urge the glibc folks to communicate better when they are going to make disruptive changes like requiring a much newer kernel. Enhance QA and Release Engineering tools to automatically discover breakages like this in advance--prior to the actual compose.
Fedora 14 Blocker Meetings are already taking a minimum of an hour	2010-07-24	We are averaging 10 minutes of discussion per bug--this will be a problem as the number of blockers grows Not getting timely feedback needed from bug assignee (package maintainer) In the absence of information from the maintainer the meeting is held up while various people try to research the problem and group discussion attempts to fill in information gaps--many times this works, but it is incredibly inefficient without the package maintainer present. IRC communication can be laggy and disorganized	Review and hound maintainers for information about bugs in the comments of proposed and approved blocker bugs as soon as they come in--don't wait for Friday's meeting Use Fedora Talk (conferencing system) to speed up discussion and keep meeting more focused stream audio to the web people without the ability to connect to Fedora Talk can listen to web stream and respond in IRC