Al Hopper wrote: > 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?
The same people who, informally, do so now. The ARC community and the (not really existent, opensolarisily) C-Teams. You do raise a good point, in that this is a proposal the enforcement of which depends on a group far, far, far less open than the ARC. I would like to see a follow-up suggesting similar for the C-Teams, they either need to operate in the open, or an alternative needs to be found. > - who is qualified to implement this policy? At least the existing ARC members and interns. > 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. The sponsor process currently deals with this (and, in most cases, does so fairly well). As does the advice of more experienced engineers, when sought. > 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. > Given it's largely a codification of existing practice, I would expect this to be self explanatory. Am I missing the point? -- Rich
