Re: time based freezes
I agree with Stefano, pretty much...
On Sun, 03 Apr 2011 at 18:15:52 +0200, Stefano Zacchiroli wrote:
> I believe we need time based freezes. Even more radically, I believe we
> need to know the freeze date as soon as possible, e.g. no later than a
> couple of weeks after the preceding release. (Obviously, transitioning
> to time based freezes warrant exceptions to the rule.)
Telepathy does a stable-branch of each major component not long before each
GNOME release, so every 6 months. In the absence of a preannounced freeze
date, we basically need to only release stable-branch versions to unstable
(with development versions in experimental), which reduces the ability to get
real-world testing on the features added by the development branch, and
find/fix the bugs before declaring it stable; chicken/egg?
With a preannounced freeze date, we'd be able to push many of our development
versions into unstable/testing (reserving experimental for only riskier
changes), and become more cautious when we get within 6 months of the freeze
date.
It'd be tempting to say "early testing? That's what (Fedora|Gentoo|Arch)
users are for", but I don't think that's a sustainable approach; finding bugs
is one of the ways in which we (should) help our upstreams.
(When I say "development versions", I mean "upstream release with new features"
rather than "random snapshot which might even work", obviously.)
> The next question is then what does "freeze" means. Does it mean that
> automatic transition to testing stops automatically at freeze date, or
> rather that no new transitions are accepted anymore (which IIRC has been
> proposed before).
For the squeeze freeze, all packages that were in unstable on freeze day
were pre-approved for the usual time-based migration (by the RT adding a large
initial number of hints), and the RT had a relaxed policy for freeze-exception
requests for a while. If that's not too much work to do again, it seems a good
compromise?
S
Reply to: