On 2013-04-02 14:29:46 +0100, Neil Williams wrote: > That is not how it actually works out. Policy changes are made which > require old packages to build with new flags, compilers and toolchain > packages get upgraded and introduce new failure modes, QA tools improve > and catch more corner cases. Those things no longer happen during a > freeze, so the bug count has a chance to go down. > > Look at the graphs on bugs.debian.org - the RC count rises steadily > outside of a freeze.
The graph is meaningless. Many RC bugs can be due to transitions, which are specific (the freeze applies to *all* packagse). This is also due to the fact that more people are working on fixing RC bugs *now* instead of doing that before. > Again, you're missing the whole inter-dependency issue. A new piece of > software can introduce / reveal bugs in previously working software. Or > a previously working piece of software can start to fail because > hardware has moved on and is able to push more data through the > software than previously envisaged leading to complex threading / > timing issues. But my point is that this is true only for some particular packages and this doesn't prevent developers from fixing RC bugs. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402152052.gh31...@xvii.vinc17.org
