On Jan 28, 2008 1:00 PM, Keith M Wesolowski <keith.wesolowski at sun.com> wrote: > On Mon, Jan 28, 2008 at 12:42:25PM -0600, Shawn Walker wrote: > > > Three letter acronyms without an explanation don't mean much. > > I'll elaborate, then. You asked: > > > Those dev processes seem to severely restrict "revolutionary changes" > > rather than encourage them. > > > > However, I would like to be proven wrong. > > ZFS is revolutionary change. It was accomplished within the framework > of the very process you asserted restricts and discourages > revolutionary change. There are plenty of similar examples. These > constitute an existence disproof of your assertion. As for QED, see > http://en.wikipedia.org/wiki/Q.E.D. > > The bottom line is that these development processes encourage thorough > understanding of all changes, whether revolutionary or evolutionary. > They only discourage (prevent, hopefully) change that is ill-conceived > and/or ill-executed.
My assertion was based on community member comments that implied that full review was required before starting a project, developing it, or releasing a prototype. Since that is not the case; I withdraw that assertion. > > Please explain to me how an OpenSolaris contributor can: > > > > 1) start a project > > > > 2) develop it > > > > 3) go to arc, etc. when they feel it is appropriate > > > > 4) integrate > > > > If step #3 is required before they perform #1 and #2, then we have a > > problem. > > Design and architectural review as well as interaction with subject > matter experts are strongly encouraged early in development and > throughout development as appropriate. That said, ARC review and > code/design review are only *required* prior to integration. So it > seems that the existing/historical process that is in place already > has the characteristics you insist are required. Strongly encouraged and required are two different things. I strongly encourage it to the developers that I work with as well, but it isn't required because it isn't always the best way to approach a problem. > That said, a project team consisting of inexperienced engineers that > does not engage early and often is all but certain to fail. I don't > want to hear whining from such project teams whose ARC cases are > denied or who spend twice as long redesigning or recoding as they did > the first time around because someone pointed out during review that > what they did was a pile of crap. That's why any description of the > development process needs to do everything it can to convey its > positive value. The process exists not to put obstacles in your way > but to help you succeed. In an *Open* project though, you have to allow such failures. People rarely learn as much from success as they do from failure. To me, good engineering for OpenSolaris should be encouraged; but not required until the point where it actually impacts the greater community (integration). Despite your assertions of failure; many OpenSource projects have been quite successful without following the early review process. In an *Open* project, developers have the freedom to fail, not just to succeed. -- 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
