On Jan 28, 2008 12:42 PM, James Carlson <james.d.carlson at sun.com> wrote: > 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.
No, I'm trying to clear up when it is actually required. > 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. Earlier is only better if you are ready to have a review. If I am not prepared for ARC, etc. to review something because what I am doing is just a rough prototype; there is no point in taking it to ARC. The when and how are of course subject to interpretation. > 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. I'm well aware of what the purpose of ARC is from a generic perspective; I have to deal with something similar at my employer. I agree with you in a general sense. Obviously a good design is important as the foundation of a project. However, I just want to be certain that a developer is free to experiment without being required to go through a review process before they are ready. > > 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. Well, that's where my confusion is. I continue to see postings by community members that are implying that releasing a prototype, as an example, of a particular project is somehow "violating ARC"; which makes no sense to me. I just want to clearly understand *when* a developer is actually *required* to go through ARC, etc. Cheers, -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben
