Alan Coopersmith wrote:
> John Plocher wrote:
>> What, if any, is the relationship between a Project and the ARC reviews
>> done by the ARC community?
> 
> Projects may or may not produce artifacts which will need ARC review
> when they have progressed far enough, it depends on the type of project
> and if they intend to integrate changes into a OpenSolaris consolidation.


This then begs the question of what kinds of OpenSolaris projects wouldn't
integrate into an OpenSolaris consolidation?  What benefit is there for
the OpenSolaris meta-community if its resources (project hosting...) are
used for things that are not targeted at OpenSolaris?  Or am I confused
(again)?  Could you give an example of what you are thinking here?

As I parse your response, I am struck by the potential for architectural
expectation impedance mismatching if an OpenSolaris Project usually maps
to zero ARC cases unless [list of exceptions] trigger additional ARC work.

Is there any way to set the default bit the other way - so that
interaction with the architecture community is the norm?  So that,
as a project "does" architectural development, the way it does so
is via interactions with the architecture community?

As an example, presume that all projects had an "ARC preinception review"
soon after their creation, where they and the arc community have a quick
and simple conversation relating to the intent and goals of the project,
the result of which is a mutual determination of what kind(s) of future
ARC interactions (including "none") are appropriate?

In this view, an OpenSolaris Project maps to one or more ARC cases,
as the needs of the project dictate.

As they say, "ARC early and often".

   -John (one of the "they's")



Reply via email to