SQL Server 2005 (code named “Yukon”) is built on the Whidbey platform. The integration of the Whidbey .Net Framework with the SQL server engine is well known; this provides the “SQLCLR” functionality that enables managed code stored procedures, user defined types, aggregates and functions. What’s less well known is that the Yukon administrative and business intelligence (BI) tools are largely written in managed languages and heavily leverage the Whidbey .Net Framework. In addition, the Yukon tools incorporate VS Whidbey components and several of them are implemented as VSIP applications that plug into VS. Yukon developers are daily users of VS Whidbey and the SQL buildlab utilizes Whidbey compilers and tools to build Yukon on a daily basis. It would be fair to say that the SQL division really cares about Whidbey progress and quality.
With so much exposure to Whidbey, it should come as no surprise that the SQL division reports Whidbey bugs. For much of the product cycle we’ve seen a slow but steady decline in the total active Yukon originated Whidbey bug count. The incoming rate varies with SQL’s transitions to newer Whidbey builds and QA activities (bug bashes, stress runs, etc.) and we’ve been consistently resolving bugs at a slightly higher rate. Whilst the total active number was never very large, as we close in on Whidbey Beta2, our fix rate has increased and we’re down to a small number of remaining Yukon originated bugs. Most of these are SQLCLR stress related bugs, which is not unexpected at this point, with teams focusing on meeting stress and other release criteria goals. We know we can count on a bug flow from stress runs to Whidbey teams until release criteria are met and Yukon is ready to ship
Yukon‘s Whidbey exposure is clearly good news for customers. Having a Microsoft division the size of SQL pounding on Whidbey and probing its limits helps smooth the way for customers to extract great results from Whidbey when it ships next year.