Re: Staged Freezes
Chris Leishman <masklin@debian.org> writes:
> The problem at the moment is that no-one wants to freeze, because we
> don't know how long we will be frozen for - and in that time things
> get stale and old. And why don't we know how long we will be frozen
> for? Because some "critical to release" packages (like
> boot-floppies) are not stable and we don't know how long they will
> take to become so.
> However - IMHO if we don't freeze, then we are in the same position
> as unstable always is - at any point there can be an update that
> will cause a different "critical to release" package to fail. Who
> knows - in a month when we have boot-floppies working, some other
> new or updated package might (or new policy) might still prevent us
> from freezing for the same reasons..
No, this is wrong. I don't believe in this diagnosis. The fact is we
want the literal freeze cycle (no new packages) to be as short as
possible. To do that, we need to go into freeze with a functional:
* base system (it's not even really functional yet, but close;
note that some architectures don't even have their release
kernel in place yet!)
* boot-floppies (ditto)
* debian-cd (not sure)
> Bit of a catch 22 really. If we freeze, then things can stabilise,
> but they might also get stale. If we don't, then things won't get
> stale, but they may not stabilise quickly.
Yet, the stability of the above items can be addressed independantly
of the stability of all the other packages in the system. I applaud
the release manager's decision to wait until the core shown above is
ready before freezing.
> 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_.
I don't understand how the boot-floppies team is to complete and
stabilize the boot-floppies if we're not allowed to release updates?
If you're saying we should put base into freeze, then that at least
makes some sense.
> 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).
You're just saying, or trying to say, "lets freeze base". This is
fine but I don't think it will really fix many problems.
> 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.
The problem with that idea is that we don't have copies of all
backdated versions. A better plan is simply to drop non-critical
packages where RC bugs have not been fixed. That is what we currently
do.
> 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.
Well, I would actually try to announce to all, "please don't upload
major new versions unless they are critical to the freshness of
potato." So I guess I'm more of a proponent of the "common sense"
side...
Anyhow, given the fact that right now the release manager considers
the stability of boot-floppies the delay to freezing rather than the
RC bugs in potato, then your semi-freeze proposal doens't really do
much to help whatever problems people think we're trying to help.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: