Re: Partial freeze?

[Mike Goldman <whig@by.net>]

I'd be in favor of doing this *now*, but I'm not sure if it can be enforced with
current tools.  If dinstall can be configured to selectively hold updates to
certain packages, pending ftpmaster approval, while letting through others, let's
do it.  Even if it cannot be enforced, I think that maintainers of release
critical packages should be asked to immediately refrain from any updates which do
not fix important bugs, and nothing else.

The alternative scenario, which is just absurd, is to keep our fingers crossed
until the next "scheduled" freeze, hoping that we can actually do it, but
realizing that it may be delayed again, and again.

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.
>
> However, new uploads can continue while this stuff stabilises - as long as
> they don't cause problems with the "critical to release" packages.  If they
> do, then the freeze rules apply to that upload (no new code).
>
> Eventually we freeze the whole distribution for a very short time to clean
> release critical bugs in non-core packages.  We should take a fairly hard line
> on these, and basically say that if there was a version without _new code_
> that didn't exhibit the problem, we backdate to it rather than bugfix.
>
> Ok..conclusions from this idea... This _may_ lengthen the freeze time, since
> we are effectively doing 2 freezes.  But the second phase (the phase that can
> introduce stagnation) will be much shorter than it is in our current situation.
>
> Another conclusion may be that this just sounds like common sence, and there
> is no need to make it official...but I've always found these things work much
> better when they are enforced.
>
> The last remaining question is how workable this concept is....