Mark: > I believe this may be the first case that officially refers to (the > defacto state of) an OpenSolaris distribution and delivery platform > that's never been fully disclosed to the ARC. While I do not care at > this time to get into semantics about what that means to the "community" > at large or to the ARC itself, I would like to pose a practical question > to both ARC bodies that operate "openly". How do we review cases that > target the OpenSolaris(tm) repositories? Is the "published" material > from the installation community sufficient to provide background > material? Is there truly no internal-only material or information that > is currently being used or would be used? If I have questions about the > delivery vehicle itself (release modes, release architecture, > integration, etc), do I ever get to raise them, and if so, in what forum > or manner?
Although there may be some things in OpenSolaris that have not gone through careful review, the bulk of it has. So, I'd expect problems to arise, for example, if a case wants to import interfaces that have not yet been ARC'ed. I believe that most examples of non-disclosure have simply been caused \ by oversight or a need to integrate something quickly and without time for paperwork. So, as we identify particular areas of non-disclosure, we can always just work with the project teams to resolve those problems as they arise. It might be necessary to try to get undisclosed projects to go through ARC in the near term if we feel that the interfaces they expose are in particular need for review. For example, if we expect those interfaces to be used widely. Another point is that I bet a number of undisclosed projects are free software projects. Often times such FOSS modules declare their interfaces as Volatile anyway. We depend on the upstream communities to establish reasonable interface compatibility, and many upstream communities that we depend upon have fairly solid ABI rules (e.g. libgtk and other GNOME Platform libraries). There have been some situations where reviewing such FOSS projects has been helpful. The GNOME Desktop team tries to ensure that feedback from ARC is related upstream and there are several examples of how ARC suggestions have caused change upstream. For example, GNOME panel applets are now stored in libexec (/usr/lib on Solaris) instead of /usr/bin due to comments from a long-ago GNOME ARC review. The external community did about half the work to solve that problem, and the Sun GNOME Desktop team did the rest. So, I do think there is value in ARC'ing FOSS cases, but we probably want to most focus on those interfaces that we think have higher priority, are more likely to be used in ways that require interface stability, etc. > I'm honestly not trying to pick on the other project. I've just been > (sadly) expecting the day when cases would come through mentioning > "/Solaris.Next" explicitly without ever having defined that in a way > that provides knowledge that can be applied practically. My intention > here is to raise the general question without derailing the case which > mentions Solaris.Next repositories so profoundly -- and which for every > other intent and purpose sounds like a perfectly valid and completely > obvious self-review case. There would be benefit in defining what the expectations and ground rules are for modules that wish to integrate into Solaris.Next. Though, I'd think they would be fairly similar to the rules we have today. They probably need to be amended slightly to address the fact that some of the OS may not be disclosed and how ARC deals with that. To me, it doesn't seem like a big problem if parts of the OS are undisclosed. I guess one question is what degree of disclosure is needed to be a part of Solaris.Next? Does it need ARC review, for example? I'd assume that, moving forward, that it would make sense to continue reviewing modules as long as people can be found to do the write ups. Brian
