PSARC 2008/625 - Streamline ARC 20Q

[James Carlson]

John Plocher writes:
> 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?

One of the big (and obvious) differences is that we have automated
tools in place to check for common mistakes in some of the things in
the first list, and we generally don't have tools in place for much
(if any) of the BP issues.

Another important issue is that being able to use the tool set
(compiler, hg, and so forth) is a basic requirement to do anything at
all.  It's in the developer's face every single day, and thus gets
practiced often.  The nuances of patch delivery, security practices,
internationalization and other "best practice" topics simply are *not*
part of the ordinary development experience.

Heck, many developers aren't even experts with the tool set.  Many
don't quite the details of working with lint, or how the makefiles go
together, or what the build tools themselves are doing.  They _often_
don't need to know this and are instead more deeply involved in the
particular technology that they're developing.  That might be
lamentable, but I don't think it's actually avoidable.

These extraneous things are details that a project team typically
ignores until the end (if they're examined at all), and only then does
someone seek out an expert to help them out (or they just stumble
ahead through integration, possibly with bugs).  I've certainly been
there myself.  I'd be surprised if anyone's done a non-trivial project
and not bumped against "you want me to do a what with who?" sort of
issue.

Also, the list that you gave is not really all that homogeneous.
Among those things, not so many are really experts in DDI/DKI or in
POSIX -- or really need to be in order to get their work done.

> What can we do to make 
> them more relevant?

That's a good question, but I don't think I have any good answers.
Many things are in the BP list because there's no other clear way to
handle them; they're design level issues that you really can't
"enforce" through any simple tool set.

> 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.

Unfortunately, it's more than just ARC awareness.  Many of those BPs
contain information that's rather detailed and related to one
particular domain: in other words, it may be too much to expect that
even ARC members are experts in every single one of those areas.
(Quick and without looking: what chemicals are on the 'lead-free
hardware policy' list?)

> 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.

That's exactly why I think a single "do you follow all the rules?"
question is pretty close to worthless.

The way I actually envision this to work is that non-trivial projects
should show up for an inception review.  During inception, the ARC
members can say things like, "it looks like you're making security-
related decisions, so do make sure that you review this list of best-
practice documents, and be ready to explain how you comply with those
practices during your commitment review."

Yes, that's annoyingly repetitive, and, yes, it'd be great if project
teams could just automatically determine what things they need to do
even when those things are far outside of their domain of expertise,
but I do think that *expecting* and depending on them to do that is
too much.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677