Howdy gatelings,
As shown on the ON Nevada build schedule [1], the content of builds 126
thru 132 will be partially restricted to stabilize the OpenSolaris 2010.02
release. Apologies that this is shorter notice than we usually provide;
this schedule is tentative, subject to confirmation in the near future,
and has only recently firmed up enough to be able to announce this. In
particular, the upcoming builds (126-129) are on fairly firm ground, but
the later builds (130-132) are on something more like quicksand in terms
of our certainty about the timing of the next release (which again, is
*tentatively* slated to be 2010.02).
Here are some guidelines on how we approach such milestone builds, and ON
CRT (change review team) advocacy in general; note that the "milestone
builds" section is different than it has been:
* 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 for a build or
two in advance. But to improve quality and focus, we are extending that
practice this time around.
* N-7: no restrictions
* N-6 thru N-3: RFEs and bug fixes that are low-impact, plus RFEs and
projects from targeted technology areas. More on this below.
* N-2: bug fixes only
* N-1: stopper fixes only
* N: stopper fixes only
* N+1: no restrictions
There are 7 technology areas that are the focus of this release:
* Installation
* Packaging
* System Management
* Virtualization
* Security
* Storage
* Platform support & drivers
Projects fitting under one of these umbrellas should send e-mail to
Miguel.Ulloa at sun.com to get on the list of approved projects. Note that
this has already been communicated internally, so it is our expectation
that most if not all projects are already on our project log.
RFEs that are "smaller than a breadbox" (i.e., low-impact [in the RTI
sense]) are allowed. For RFEs that are "bigger than a breadbox but
smaller than a car", especially those under one of the above technology
areas, check with me and Miguel, and we will help you with the vetting
process. For RFEs that are "bigger than a car", you are really a
project, so please follow the instructions for projects.
* 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 (125 in this case) before the milestone in question,
defer it until the next unrestricted build (133 in this case). When in
doubt, consult the tech lead (i.e., me).
-- John
[1] http://opensolaris.org/os/community/on/schedule/
