Paul has already eloquently noted that the release date of Fedora 13 has changed to May 25, 2010. This was disappointing after the AMAZING effort that went into meeting the original challenge–addressing all of the outstanding blocker bugs by May 6, 2010.

Several months ago I kicked off the original effort for enhanced Fedora 13 release criteria.  It was really cool to see this recognized by Sean Michael Kerner as a good thing.  We still need to smooth out the process a little bit which I pointed out on the Fedora development list.

My concern was that a clear policy and a high bar had been set about what fixes were allowed at this stage of the release and then informal exceptions were being made to it.  Sometimes this creates confusion and the perception of “different rules for different people.” Our processes should be crystal clear to everyone and followed consistently.

Most good processes have room for exceptions. There are definitely times when judgment calls must be made by certain teams or people to get the release out on time.  After completing almost 40 releases of Fedora (test and final releases), we should be fairly familiar with what those situations are and who needs to make them. I plan to propose a light weight process for transparently documenting those situations and which teams and people act on the release’s behalf.

This is important if we want a project and release processes that are raptor proof.  Our release processes will never scale or be sustainable if only certain people have the knowledge and experience to make judgment calls.  We can’t document every possible decision that might be needed.  We can create a general framework explaining what matters, who decides, and how.

Several releases ago the Fedora feature process went through the same iterative process to reach maturity and it is normal that this process follows the same path.