Howdy gatelings, As shown on the ON Nevada build schedule [1], the content of builds 108 and 109 will be partially restricted to stabilize the OpenSolaris 2009.04 release. Here are some guidelines on how we approach such milestone builds, and ON CRT (change review team) advocacy in general:
* use good judgement Not all bugs and RFEs are equally important. If you are headed for integration into a restricted build, consider delaying until after the restriction has been lifted. The goal of restricted builds is stability and bug reduction, not new features. Expect your CRT Advocate to discuss this with you if you file an RTI during the restricted period. * shrink to fit All of our processes are designed to shrink to fit the occasion. If a given change is low risk, low impact, and high reward, then it needs less scrutiny. Things that are higher risk, higher impact, or lower reward will receive more attention, especially during restricted builds. * milestone builds Traditionally, we have clamped down on milestone builds. But in this era of regular (more or less semi-annual) milestones, the following seems appropriate (in this case, N=109): * N-2: no restrictions * N-1: RFEs and bug fixes that are low-impact * N: RFEs and bug fixes that are low-impact and low-risk * N+1: no restrictions * code reviewers We have often required two code reviewers for milestone builds in the past. This, however, also falls under the above points about good judgement and shrink-to-fit. So two (or more) reviewers are recommended for milestone builds, and also for a high-risk or high-impact change at any other time. If you think an RTI's risk or impact might be too high, and you missed the last unrestricted build (107 in this case) before the milestone in question, defer it until the next unrestricted build (110 in this case). When in doubt, consult the tech lead (i.e., me at present). -- John [1] http://opensolaris.org/os/community/on/schedule/
