On Jan 28, 2008 4:14 PM, John Plocher <John.Plocher at sun.com> wrote: > Shawn Walker wrote: > > 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. > > I would too, which is why that is not what has *ever* been proposed. > > What has been proposed is that the Project's interactions with the ARC > /begin/ at project creation time, and /conclude/ before the project > asks to integrate. The "formal proposal" is nothing more than a bug > report, RFE or OS.o Project Instantiation Notice - certainly nothing > heavyweight like a functional spec or requirements document.
To me, this only applies when your "project" has a definitive conclusion. As an example, my idea for a project that would maintain a "bleeding (hemorrhaging? :)) edge branch of the ON tree shouldn't require any ARC at all, because, as a whole it never intends to re-integrate. Meaning, it doesn't really matter what's done with it; as it should, theoretically, never have an impact ;) > > anyone's approval and only when they are ready to have their work > > reviewed (before integration into the main ON tree as an example) > > The failure mode is waiting until you are done hacking before starting > the effort to understand the architectural impact of your work on the > rest of the community. > > If you wait that long, you will have already (implicitly) committed > to a large set of architectural decisions, and it will be (de-facto) > way too late to change any of them. While I can agree with that to a certain extent; sometimes you are so uncertain of an idea that you need to formulate it in code (paper napkin? :)) before you ever present it to someone for that sort of review. I might want to try several architectural approaches to something, in code, before I ever approach a process such as ARC about it. I don't think it's a "failure mode" to wait until you think you're ready. The problem with trying to enforce the "process early, process often" approach is that it encourages people to be secretive about their activities and make it look like they've done what you wanted. That, or in the case of most open source developers, they run away screaming -- scared to death by real or perceived bureaucracy. That's why I believe it has to be *strongly encouraged* as opposed to *absolutely required*. > > It should be up to the developer when they have to consult ARC, etc. > > For simple projects that have no architectural impact (as determined > /by/ the developer), the sum total of ARC interaction is when the > developer self-determines that his or her project has no architectural > impact. ~90% of the changes in a given product are completely self- > reviewed, and require absolutely no ARC interactions. > > For the rest, 15 years of experience shows that early interactions > with the ARC lead directly to better projects; late interactions > find the /same/ issues, but by then the developer has too much > invested in their implementation to change. The inevitable result > of late interaction with the ARC is frustration on both sides. Maybe that leads to a better project when the development process and goals match that of Sun's; those fifteen years of experience are certainly based on Sun's internal view, right? Obviously, I know that from a general perspective, such a review is beneficial regardless of whether it is Sun, etc. However, recent years have shown that many different approaches to the software development process have been tried, and some have succeeded in certain circumstances. As a result, because this is *Open*Solaris, not *Sun*Solaris, we need to allow for community members to approach the software development process in their own way and only enforce certain requirements where absolutely necessary. > > A good developer will know when the right time to do that is. > > Sadly, ~15 years of ARC experience shows that this is much harder to > do in practice than you imply. Either that, or we don't have good > developers - a conclusion I'd disagree with strongly :-) I guess what I'm trying to say, is that you can't come up with a "one size fits all" approach here. Sun's processes are not going to fit every project that the community wants to engage in. Likewise, the community's desired processes aren't going to fit Sun's. There needs to be some compromise between the two. 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
