[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Fedora Core 6 Draft Schedule



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]