On Thu, 2010-08-12 at 13:50 -0500, Mike McGrath wrote: > Any of the QA guys have any way to measure the the most common cause of > our slips? Is it usually stuff we're our own upstream for? Is it > integration? Is it bugs that were introduced months ago but only recently > found or bugs that were just introduces in the couple of weeks before > release? Not a super convenient way, but you can do it by going back and looking at previous blocker meetings and go/no-go meetings. I've done this once when there was some debate about how early the blocker issues were identified. Most blocker bugs are in anaconda. This is simply because it's the component most *likely* to have blocker bugs, because of the function it performs. We usually catch most initial blockers for any given release at the first TC stage. Bugs we slip for are usually ones identified at that stage that we couldn't fix in time, bugs introduced between TC and RC by non-critical changes to critical components (this is something that could bear to be tightened down), and bugs introduced or exposed by other blocker fixes. A common case is, say, we identify a bug in TC#1 that completely breaks FTP install; then the anaconda team fixes that for RC#1, but we discover that the same FTP install path is broken at a later point. We couldn't have found that at TC#1 time, because it's hidden by the earlier breakage. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
