Sadly, we had our first Fedora 19 delay last week. I actually was trying pretty hard to get this to be the first release where we didn’t slip at all, but alas, this was not to be.

The good news is this is nothing like the Fedora 18 situation. In F18, when we hit the first go/no-go for Alpha we were barely within shouting distance of having anything releasable, and Beta was worse: we didn’t just have a few stray bugs, we were still writing bits of the installer.

What’s holding up Fedora 19 Alpha, in contrast, is two bugs in UEFI installation, and that’s it. (Note for the haters: none of the bugs has anything to do with Secure Boot). The installer is in fine shape, except for an issue in the custom partitioning screen which we’ll try and slip a fix in for. All the code that was meant to be written by now is actually written, it’s all working pretty well, and most of the functionality of the installer is pretty solid. There have been a ton of UI improvements since Fedora 18 based on both online feedback and real-world usability testing and observation, as well.

So it sucks that we had to slip, but it’s a much different situation from Fedora 18, and it’s been a lot lower stress – we’re not running around trying to keep tabs on 15 bugs and 5 features that aren’t written yet, right now we’re really just waiting on upstream review of a patch for the last UEFI issue (the fix will need to go into the upstream kernel, and we won’t put it in Fedora until it’s in an approvable state for upstream merging).

We made some fairly significant changes to the release validation process prior to the Fedora 19 cycle, and we’ve been happy with how they’re working out so far. At FUDCon Lawrence, the QA members present came up with a plan to revise the “nice-to-have” process by which we track fixes that we want to take through the Alpha, Beta and Final freezes. That proposal was sent to the mailing list, where in turn, a lot of the group members who weren’t at FUDCon contributed improvements to it. We rolled out the changes to what is now called the freeze exception process – because, you know, it’s for freeze exceptions! – ahead of the F19 Alpha validation process, and it’s been working out well so far. It really boils down to renaming “nice-to-have” to “freeze exception”, but there are some devils in the details, and it makes what was a somewhat poorly-understood process much more understandable.

I drafted up some substantial revisions to the layout and content of the release criteria just ahead of the Alpha release. The changes have been put into practice for the Alpha release criteria (compare with the F18 Alpha criteria to see the changes), and will go into place for the Beta and Final criteria before we reach those milestones. The idea is to have a shorter ‘main’ text for each criterion with details and ‘commentary’ as expandable extra paragraphs, and to lay out the criteria better so it’s easier to read the page and to refer to specific criteria. So far the changes seem to have been integrated into the process smoothly enough.

Finally, we made some tweaks to the blocker bug process and blocker review meeting process to try and expedite blocker (and freeze exception) review a bit. We introduced the concept of automatic blockers to try and cut down a bit on unnecessary review of issues that are very obviously blockers, and tried to set things up so blocker review meetings don’t run on forever. Again, those changes seem to be working out well.

So I’m feeling good about the Fedora 19 cycle so far! I’m hopeful there’ll be very few (or no) further delays after this first one, and we’ll wind up with a very solid release, with significant improvements to the new installer.

I do not have a UEFI System, but I can report that TC5 was installed without a hassle. F19TC5 anaconda had a few new lines of informational text that helps an inexperienced person understand how/when to move to the next step in the installation process.