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

Staged Freezes [was Re: Partial freeze?]



On Tue, Nov 09, 1999 at 07:23:23AM +1100, Chris Leishman wrote:
> 
> How about this then:  We identify those packages which are considered
> "critical to release".  This would include packages like boot-floppies and
> policy.  Then we declare a _freeze on those packages_.  The same freeze rules
> apply - only bug fixes to these packages allowed.
> 
I believe staged freezes is a better name for this and it shouldn't be restricted
to only 2.

A good way of partitioning the packages is as follows:
  1) everything in base and the boot-floppies

  2) critical apps (for example gcc, X and the parts of perl not in base) plus
     libraries which only depend on base

  3) libraries which depend on other libraries

  4) everything else

Partitioning the packages could be automated, with a list of exceptions to take care
of things like X. Even complicated systems like gnome fits into this partitioning quite
well.

If we wanted a 4 month release cycle, stage 1 would freeze 6 weeks after the previous
release and each succeeding stage after an additional 2 weeks. This would leave a 2 week
freeze for stage four followed by a final 2 weeks of testing.

What this does is to remove the current rush of everything happening at once.
Those parts more critical to the release, and needing more testing, get more time,
while allowing less critical parts to be more current. It also minimizes changes
that would break packages that are already frozen. For the most part, changes
should only cause problems with packages that haven't been frozen yet.

Some people may want to collapse 3 and 4 into one freeze. While this is possible,
it can only be done if complicates systems, like gnome, are managed carefully
(it was gnome that made me decide to split them).

-- 
James (Jay) Treacy
treacy@debian.org


Reply to: