PSARC 2008/625 - Streamline ARC 20Q

[John Plocher]

James Carlson wrote:
> John Plocher writes:
>> they need help
> 
> It sounds to me like you might be expecting at least some teams
> (perhaps "many") to be fully conversant in all of the Best Practices.
> I'm not sure that's realistic.

We already expect project teams to be conversant in cstyle, compiler 
usage, webrev, hg, ddi/dki, posix, etc etc etc.  What is special about 
the things enumerated in the BP/P archives that makes them topics that 
teams aren't expected to be conversant in?  What can we do to make 
them more relevant?

I don't want to imply that it is all on the project team's plate - if 
there is ignorance or confusion, those of us who are more ARC-aware 
need to be accessible and willing to step in and help.

(BTW, this is why I keep pushing to get someone from *every* project 
team to be an ARC member - the more people that get the ARC disease, 
the better the quality of the projects we produce, and the easier 
their review becomes.)

So, yes, I do expect every team working on OpenSolaris to have a
reasonable amount of clue as to the impact of their project on the 
systems we all are building, including the content of the BP&P 
repository.  Maybe not "fully conversant", but certainly more than 
"completely naive and ignorant" as Scott's paraphrase implied.  If a 
team has not taken the time to figure out how their project will 
impact the system they are modifying, they have no business 
integrating into it*.

The failure mode that I fear is that nobody bothers to answer the "do 
you know what the ARC BPs and Policies are and how they apply to your 
project?" question, the integration-quality of our OS goes to hell and 
the ARC job becomes one of trying to reverse engineer and remediate 
every project.  Uugh.

   -John
____
[*] As I reread this, it seems as if I'm trying to make it harder for 
everyone to do simple things.  As the FOSS Checklist discussion 
indicated, there really needs to be something for the multitudes of 
"we just want this to be available on OpenSolaris" porting projects so 
that we don't unwittingly force them into an inappropriate integration 
scenario.  Some things can and should be able to ignore BP&Ps, and we 
owe it to these project teams to help them understand which ones and 
when they should.  If we did this right, Scott would instead get a 
response like "Yes, we fit into exception pattern A-2".