OpenSolaris

1. Community: OS/Net (ON)
   1. Blogs
   2. Development Process
   3. Developer's Reference
      1. Introduction
      2. Prerequisites
      3. The Source Tree, part 1
      4. The Source Tree, part 2
      5. Building OpenSolaris
      6. Installing and Testing OpenSolaris
      7. Integration Procedure
      8. Best Practices and Requirements
      9. Glossary
   4. Discussions
   5. Installation (from source) Quickstart
      1. Annotated nightly(1) Mail Example
   6. Currently Known Issues
   7. CRT
      1. Advocates & Sponsors
      2. Becoming a CRT Advocate
      3. Charter
      4. RTI nits to avoid
      5. Sponsor Tasks
      6. Becoming a Sponsor
   8. Schedule
   9. ONNV Flag Days, Heads Ups, and Project Integration History
      1. All
      2. Builds 91-95
      3. Builds 86-90
      4. Builds 81-85
      5. Builds 76-80
      6. Builds 71-75
      7. Builds 66-70
      8. Builds 61-65
      9. Builds 56-60
      10. Builds 51-55
      11. Builds 46-50
      12. Builds 41-45
      13. Builds 36-40
      14. Builds 31-35
      15. Builds 26-30
      16. Builds 21-25
   10. Leaders
   11. Observers
   12. Putback Logs
   13. Developing Solaris
       1. Quality Death Spiral
   14. wx
   15. findunref and unreferenced files
   16. Bourne/Korn Shell Coding Conventions

heads up: reminder on restrictions for builds 78 & 79

Date: Mon, 29 Oct 2007 23:24:36 -0700
From: John Beck <jbeck at eng dot sun dot com>
To: onnv-gate at onnv dot eng dot sun dot com
Subject: heads up: reminder on restrictions for builds 78 & 79

This is an updated version of the heads-up I sent on August 30, when builds
77-80 were only on the horizon.  But as of tonight's clone update a few
minutes ago, 77 closed and 78 opened, so the following needs restating.

As shown on the ON Nevada build schedule [1], the content of builds 78 and 79
will be partially restricted to stabilize the next Solaris Express Developers
Edition (SXDE) 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 (the goal would seem quarterly) milestones, the following seems
  appropriate (in this case, N=79):

  * N-2: no restrictions
  * N-1: RFEs and bug fixes which are low-impact
  * N: RFEs and bug fixes which 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 (77 in this case) before the milestone in question,
defer it until the next unrestricted build (80 in this case).  When in doubt,
consult the tech lead (that's me now).

-- John

[1] http://opensolaris.org/os/community/on/onnv_schedule.txt