So one of the discussions that was held at FUDCon in Boston a week and a half ago was around the schedule for Fedora Core 6. We started off with a discussion around the merits of a six month vs a nine month schedule. While the longer schedule did allow us to get more "stuff" in, from my point of view of trying to get the release out, the more "stuff" actually made it significantly more difficult to finish the release. Also, a six month schedule tends to make it so that we line up better with a variety of other projects that we depend on. There was more, but suffice to say that the overwhelming consensus was that six month schedules work "better". So, given that, here's the pass at the schedule for Fedora Core 6. Note that there is a slight change from the discussion at FUDCon due to the Red Hat Summit -- trying to get test1 frozen and available to mirrors when the release team is in Nashville isn't likely to work :) The dates line up as 7 June - FC6 Test1 Development Freeze 14 June - FC6 Test1 Release 5 July - FC6 Test2 Development Freeze, feature freeze 12 July - FC6 Test2 Release 9 August - FC6 Test3 Development Freeze 16 August - FC6 Test3 Release 12 September - Final Devel Freeze. All package builds completed. 20 September - FC6 General Availability This is all reflected at http://fedoraproject.org/wiki/Core/Schedule -- we'll be trying to use this for the canonical schedule location rather than off of fedora.redhat.com to help make things easier for updating. Beyond just dates, I'd like to also propose an attempt to actually try to have some discipline around freezes also. With FC5, there were a lot of things which people wanted to get in late in the cycle. If we set the proper expectations up front, hopefully we can avoid some of the tension and mistaken expectations about the release process. So, I'd like for all "major" features to at least be starting to be in a testing state in time for Test1 with a drop-dead date (ie, the call is made on whether the feature is complete enough to make the release or if it should be dropped from the release and we'll pick it up the next time around) of the Test2 freeze. This will help to ensure that we're more functionally complete earlier and therefore have more testing and a better final release. Comments, feedback, etc? Jeremy
