Shawn Walker writes:
> I'm aware of the release binding concept. However, others seem to
> imply that before work can even begin on something, a formal proposal,
> etc. has to be done and something has to go through ARC.
>
> I don't agree with that view.
>
> A developer should be able to start work on something without getting
> anyone's approval and only when they are ready to have their work
> reviewed (before integration into the main ON tree as an example)
> should they be required to perform ARC, etc.
I think you're misunderstanding how ARC review works.
Getting an early review -- the earlier the better -- is to your
advantage. Note that I said "review," and not "approval." The two
are separate; approval follows a completed specification and either a
vote of the ARC members or (for "obvious" changes) a fast-track timer
expiry. "Review" is as simple as submitting materials and asking for
comment.
Early review is to your advantage because:
- It means that the ARC members become aware of (roughly) what
you're doing. This allows them to comment on _other_ projects
that come before the ARC and that may end up causing you trouble
down the road.
- It allows the ARC members to suggest areas where your
specification could be clearer, or point out issues that you may
need to discuss with other project teams, or even point out topics
(such as upgrade or diskless operation) that you may have ignored
entirely.
For purposes of a review, it doesn't matter if you have a lot of
"TBDs" or other blank areas in your plan. ARC review helps you by
getting wide exposure early. If you wait until later, when all of the
bits are nailed down, you may end up with some very nasty surprises.
If you do your first review early, then when you seek approval, you'll
end up having little to discuss with the ARC members. All of the
serious issues will have been anticipated, and the approval part will
be a breeze. That's the way it's _intended_ to work.
In the same way that it's foolish to wait until a day before putting
back to get your code review, or until you've already begun automated
testing before doing a design review, it's similarly not a good idea
to _start_ your ARC review at the very end of the development cycle.
In my experience, it's the projects with the very worst problems that
do this. They mistakenly believe that the ARC is merely a checkpoint,
a hurdle to cross, a barrier to overcome before integration, rather
than a technical review process. If you treat any of the reviews you
need in that way (or, for that matter, any of your reviewers), your
results will almost certainly show it.
> It should be up to the developer when they have to consult ARC, etc.
>
> A good developer will know when the right time to do that is.
I would agree with that. However, by stating your opposition in terms
of a hypothetical "approve before starting work" process that simply
doesn't exist anywhere (either in traditional Solaris or OpenSolaris),
I think you've misunderstood how the ARC works.
--
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
