When should developers interact with the ARC?

When should changes to the architecture of the system be reviewed and/or approved?

• Review as part of a high level component review, before a defacto commitment is given to a new branch or component version.
• Review at a detail-level as part of change-requests to components.  This dialog should begin as early as possible (even before prototyping begins) and finalize in ARC commitment as soon as prototyping efforts are winding down.
• Approval should be sought before significant design and implementation efforts begin
• Approval is required before a gatekeeper is permitted to allow a project to integrate its changes into the product's (or component's) source base.

When ARCs are Involved with Projects

For every engineering project, ARC interactions may occur at any point
during the lifetime of a "change request" (see the OpenSolaris development
process for
more details) .  The four most common points are:

• Idea,
• Inception,
• Committment, and
• Integration.
  (For projects with no architectural impact, there is no required ARC interaction)

Experience has shown that more regular (and early) interaction between the
ARC and project teams raises issues sooner, while they are easier
to resolve, and generally makes the project and its relatives operate more
successfully.

Idea

When an Idea for a new feature (or for a change to an existing one) occurs,
it needs to be described in a message to an OpenSolaris community alias. As
the Idea matures, additional details are added to it until it can be
articulated and accepted as a project.   Some as-yet undefined process
takes place whereby the proposal is submitted (to the OpenSolaris-ARC
alias?), archived and distributed to interested parties.

This submission involves a self-triage task to determine if the proposal
qualifies for self-review, if it can be treated as a FastTrack or if it
requires a full review. 

Proposals with no architectural impact (aka SelfReviews) proceed to
Integration at this point. 

Inception

After enough prototyping has been done by the project team to clarify any
outstanding architectural unknowns, the project team and the ARCs hold a
progress review. Depending on the complexity of the project, there may be
several such reviews before the project is ready for commitment;
alternatively, simple cases may be given commitment approval at this point. 

Fasttrack Projects which are deemed to be "too complicated" are derailed at
this point and revert to a full review; all other Fasttracks proceed to
Integration at this point.

Development (project design and implementation) starts here

Commitment

The project team submits an architectural spec - a list of architectural
changes (interfaces, components, features, etc) along with their stability
expectations - and asks for approval to integrate them into an OpenSolaris
source tree. The ARC evaluates the impact of the changes on previous
expectations, other projects, other products, and on OpenSolaris's other
commitments, and - if favorable - approves the project. 

Commitment means two things: 1) The project is allowed to deliver the
proposed change, and 2) Other projects can start to depend on this one. 

The output of an ARC review is an opinion that says

 This <list of interfaces> is new, and has <these stability levels>
 This project made incompatible changes to <this other list>,
 These lists dictate that the proposed change can only be applied to
 a {major, minor, micro (pick one)} release of the consolidation.

Integration

Development (project design and implementation) finishes here

Once the proposal has been architecturally approved and developed, the
community needs to map the changes to a set of branches that it can be
integrated into.  It starts by looking at all the branches it
currently has open, identifying the release taxonomy (major, minor,
micro) for each, and determining which of them are eligible to accept
the project. E.g.,

• The community has Major (v2.0), Minor (v1.4) and Micro (1.3.1) bugfix branches open.
• A proposal makes a compatible Stable addition, but changes an existing Unstable interface.
• The project is not eligible for inclusion in a Micro release, since Micro releases guarantee that no Stable or Unstable interfaces will break.  The Micro branch gatekeeper is tasked with ensuring that the project is not allowed to integrate into the bugfix/Micro branch.
• Because the community has adopted a "no lost features" requirement, the project team is instructed to integrate their changes first into the Major workspace and then into the Minor one.  This ensures that users who get this Minor release, and then later upgrade to the Major one won't see a feature regression for this project.

The requirement is simply that, sometime during this extended discussion (from
the initial exposure of the proposal up to the point where it is ready for
integration), the community needs to decide if they really "want" the proposed
change, and if so, where it should go.

Once this requirement has been met, this is the point where the changes are ready to be applied to the community's source tree. The C-Team (and/or its gatekeeper) is responsible for ensuring that all projects are ARC approved [1] (and include all ARC-required modifications) before they are allowed to integrate.

[1] Note that a SelfReviewed bugreport that does not have an architectural impact is considered to have been automatically ARC approved.