Op zaterdag 2 maart 2013 02:36:32 schreef Russ Allbery: > While I certainly don't want to discourage people from working on > security-related bugs, note that security-related bugs don't block the > release (because they can be dealt with via an advisory after the > release). So if the goal is to get wheezy out faster, helping with > security-related bugs doesn't really do much. Strictly speaking yes, it doesn't have a direct impact on the timeframe. However, it's still temendously useful to do. So if people are looking to sqash a bug don't find any in the non-security section, by all means, help fix a security bug. Fixing them before release is very desirable for a few reasons. The DSA process exists but is more heavyweight. Also, fixing the issues before release allows for wider testing, and the fix is present right away, on the cd images. Of special note in this regard are regressions from squeeze. We can fix everything in a DSA, but if an issue doesn't affect squeeze and does affect wheezy, it would be pity to release with it: it would make people upgrading open up holes not previously there. In fact, this goes for all RC bugs: the ones that are regressions from squeeze are the really relevant ones. When an issue is also in squeeze, fixing it is always nice but releasing wheezy with it will not make the situation worse than it was. If you check the "affected releases" checkbox on udd you can see this information for each bug. Cheers, Thijs
Attachment:
signature.asc
Description: This is a digitally signed message part.