S h i v writes: > 1. If I want to know the stability classification assigned to any > particular interface on the system (or if it is > unclassified/un-arced), is there a way to do it?
I posted on this recently in another thread, but the short answer is that there are a lot of these legacy interfaces, and each one requires judgement when a stability level is needed. Generally, things that are in use and either documented or standardized in some way are Committed. Things that are obviously intended for humans and simple debug options are generally Volatile. Other things may need more inspection. The bottom-line issue is making sure that the stability level assumed in any case matches the reasonable expectations of the users of those interfaces. For many common interfaces, the answer is pretty simple. > 2. Which are the consolidations/projects at opensolaris.org that require an > ARC? That's an interesting question. The ARC process doesn't really work unless all projects are involved in it. It's not something that can be done effectively in a piecemeal fashion, or that can be "optional." The theory behind having some consolidations not playing along is that nobody will build on the work done in that consolidation, so there are no consumers, and exported stability thus doesn't matter. Furthermore, it doesn't matter whether the software ever works reliably, so it's ok if it depends on things that weren't intended to be used. If there is such a consolidation, let's just get rid of it. It obviously doesn't produce anything of interest. ;-} I'd say that all consolidations must have a requirement of architectural review before allowing integration. It's up to project teams to determine when it's best to do that, but I'd suggest that going to ARC review early is better than later. Unfortunately, everything gets blurred on OpenSolaris, as there's really no formal structure for consolidations. I don't think that's actually a good thing. > 3. The ARC policy says it "Applies to All software produced by SMI" > and in effect since 1992. > (http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy) > In the opensolaris context, I understand the mechanism is via the case > owner who is from SMI (and not necessarily the author). Clearly, the document was written before OpenSolaris. I would interpret it now as "all software that is included in any OpenSolaris distribution." > [3.1] Can any opensolaris community project come to ARC with the > intention of making use of the body of knowledge to unearth > architectural issues of the project work if the work is to go into the > system but not necessarily via a consolidation but as a stand-alone > tool or a tool that will sit in a network repository. What? I think you're trying to make a thinly-veiled comment about Indiana, but I'm really not sure what it is you're saying. Yes, a project can live "forever" on the periphery if that's what it wants to do. I don't think that's a good thing -- it's disinctly anti-social not to allow others to build on your work -- but I see no useful law against it. > [3.2] When should a project decide that it is the right point to go to ARC? As above, earlier is better. I think you're trying to build a case against Indiana/OpenSolaris, and I just don't think it's going to work this way. -- 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
