I think there are a few issues at play here One, the process is not ideal. I'm sorry but a Sun internal process that was written years ago before the advent of opensolaris, the huge amount of change we're introducing all of the time, external vs internal code, multiple distros spanning different support timelines.....it doesn't pass the sniff test. Please prove me wrong but its going to take a bit of effort.
Two, even if you remove all of the above and say were were back in the old days where everything was inside Sun and much more contained the tools we use to do architecture review are weak. We're stuck in 1990 with email and text searches for crying out loud. The source code search engine on opensolaris.org is one example where we could tie things like interfaces, stability, and actual code together. Or at least use it if someone changes one of the interfaces it has referenced. "Oh...you want to change vhci_update_mpapi_data ?" I wonder who really uses it? http://cvs.opensolaris.org/source/s?refs=vhci_update_mpapi_data ... and yes I know thats probably going a bit down into the details for architecture review, and closer to code review, but its an example of where some of the tools should be, imho. Three, I agree with you that we need some separation between "that which stays stable" and "that which changes quickly". One of my favorite loaded questions is, "Can someone tell me what Solaris is these days?" (Outside of the marketing definitions that is...) Garrett D'Amore wrote: > I'm unconvinced that the "tools" are at fault here. > > I think the problem is more related to differing expectations from ARC > participants. On one hand there is pressure to ensure that > (Open)Solaris is an integrated system and that all the pieces play > well together without major gaps. (I.e. that each piece contributes > to some higher level "architectural vision".) On the other hand, > there seems to be pressure to integrate as much FOSS as possible, with > as little change as possible. > > These camps are often diametrically opposed, and several of the recent > cases I think are the best illustration of that. > > ARC review of the first camp is critical should be required. ARC > review of stuff from the second camp may be painful at worst, and is > probably meaningless at best. > > Hence, I believe that we need a way to separate software/repositories > so that both camps can be satisfied -- a well integrated, > architecturally clean core, with a readily accessible set of possibly > less-well integrated FOSS. (A cleaner and clearer division than we > currently have with ON and SFW, for example.) IMO, the division needs > to be visible to a system administrator (and possibly, but not > necessarily, user), as well. > > -- Garrett > > Torrey McMahon wrote: >> Before anyone asks I pulled off the psarc-ext alias. :) >> >> Outside of the process argument in general I think its clear we need >> a better set of tools. I made the same argument at arc-chairs years >> ago before opensoalaris, opensource, the huge set of FOSS was being >> packaged up, etc. >> >> Joseph Kowalski wrote: >>> >>> Back to the SDF, there weren't supposed to be any documents that >>> were just for ARC review. The documents were supposed to just "fall >>> out" of other requirements. >>> >>> This never quite worked for a number of reasons. A large one was >>> that the functional spec was too high level and the design spec was >>> probably too detailed. >>> >>> Anyway, all that I'm pointing is out the process is *supposed* to be >>> as light weight as possible and part of that is to accept a wide >>> range of possible materials. Maybe this doesn't work anymore, but I >>> still think the process should be as light of a weight a process as >>> possible for the submitter. >>> >>> That said, the recent flurries of mail seem to indicate that "there >>> must be a better way". >> >> >
