On Mon, Dec 10, 2012 at 10:02:58PM +0100, Thomas Koch wrote: > Do you think that it's a good idea to have the freeze for libc at the same > time as the freeze for sl (steaming locomotive) or iceweasel or > extremetuxracer?
It just prolongs the freeze with no real benefit. I'm happy with every leaf package that doesn't need an update during freeze, but was in a releasable state beforehand. But there's not really a benefit for packages you'd call core, as they're supposed to be of sufficient quality at all times for testing to be usable. What should be done, however, like almost accomplished in this cycle, is to have a rough consensus beforehand which major versions to ship of which package. A change of gcc default version shortly before the freeze doesn't seem too helpful, for instance. If you avoid such disruptive changes people can already test against the consensus a while before the freeze. It's ok to let other misc fixes by the core maintainers in without review before a freeze and not treat them differently. Also please let's just concentrate on RC bugs instead of the bikeshed. This seems to be the wrong timing to look at freeze management (we're calendar years away from the next one) and I think it makes sense to also include d-release@. Kind regards Philipp Kern
signature.asc
Description: Digital signature
