On Tue, 5 Jun 2007, Alan Coopersmith wrote:
> I think this is basically writing down what many of us believe to
> be the case, but haven't explicitly put into writing yet, leading
> to some confusion.
>
> I propose the OGB issue a simple statement along these lines:
>
> The OpenSolaris Governing Board hereby designates the OpenSolaris
> Architecture Process and Tools community as the architectural review
> board for OpenSolaris. All changes requiring architectural review
> that are integrated into the master gate of an OpenSolaris consolidation
> must be reviewed first by the OpenSolaris Architecture community or
> a committee established by the OpenSolaris Architecture community that
> meets openly as described in the OpenSolaris constitution.
>
> The OGB accepts as historical precedence any decisions of the Sun SAC
> that were made before June 14, 2007, including case opinions, best
> practices and policies, if, and only if, they are published openly in
> the Architecture community web pages.
>
> Careful readers may note some current practices that would no longer be
> allowed by this:
>
> 1) Cases affecting OpenSolaris consolidations being made behind closed
> doors by the Sun ARC's would no longer be allowed. If the code is
> going to be public, the ARC review needs to be too. Fortunately,
> since the latest rev of the ARC tools were put into place that make
> this easier to manage, many fewer cases are going to closed reviews
> at PSARC, but all LSARC reviews (such as JDS & various management
> tools) are still closed, and that would need to be fixed.
>
> 2) Projects targeting OpenSolaris consolidations would not be
> allowed to have ARC reviews delayed or waived by Sun PAC committees
> or policies. (Those could integrate into Sun's Solaris
> consolidations,
> just not OpenSolaris.)
Questions: Assuming this proposal has broad consensus, and I don't
see any reason why it would not achieve consensus:
- who would implement this policy?
- who is qualified to implement this policy?
- where would the required human resources (person hours) come from?
- what would be the expected response time for a review to be
completed:
o is there a concept of a Service Level type committment?
- how well would this policy implementation scale?
If the review policy required adherence to existing standards and
conventions that are unlikely to be familiar to an opensource
developer, would there be some kind of mentoring mechanism in place to
allow the opensource developer to scale the learning curve. Example:
ON Makefiles.
I think you see where I'm going with this; there's no point in a
policy unless that policy has the committed resources and scalability
to be effectively implemented.
Regards,
Al Hopper Logical Approach Inc, Plano, TX. al at logical-approach.com
Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007
http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/
