James: >>> You are correct that the interface taxonomy are not related to the >>> support model. However, it seems that many ARC cases don't include the >>> support model. There's no area for us to specify the support model of a >>> module in the ARC one-pager template. >> ARC has a sort of black & white worldview. If it's Volatile or higher >> then it is supported. If it is Private, then it is not supported. > > That's not quite true. > > Support or the lack of it is a business decision. The interface > stability classification system says *NOTHING* about support. > > What it gives you is the interface stability. In other words, it > tells you when and how an interface might change, and how other > software must be built or structured if it depends on those > interfaces. > > It says nothing about whether anyone can or will answer the telephone > when you call about a problem. It doesn't even say whether the stuff > will _work_ at all.
This is probably true in some abstract sense, but in a practical sense it is probably reasonable to assume that most project teams do have a relationship between which libraries they mark as most stable, and which libraries they most support for end-use. At least within the JDS team, this assumption is pretty much valid. >> ARC >> does not support the idea of providing interfaces that are not supported >> for end-users or developers to play with. > > That's not true. Consider "EV," "Beta Test," or even /usr/demo. > > The important thing the ARC expects is communication -- tell people > what you're doing and how. If you can manage to do that, then you'll > be at least 50% along the way. The difficulty for our project team is that there are many desktop interfaces which are really not stable enough to encourage end-use. We currently ship them because there are various desktop programs which depend on them but we don't want to make strong commitments that we will support them. Based on the above, it sort of seems like it would make sense to make such interfaces private and not ship header files. No? The problem comes into play because there is an external free software community out there publishing API docs, and otherwise encouraging people to get involved, use the interfaces, and help develop the interfaces, help them evolve and become more mature. Further, there tend to be various free software projects which end up depending on such interfaces. While perhaps a bad practice, some Solaris users still want to be able to download, build, and use such programs as they currently can do on Linux. It isn't clear to me how a library, like libgweather which is needed by the GNOME panel applets, could be sensibly delivered as "EV", "Beta Test" or /usr/demo areas. This may make sense for true end-user demoware, but does it make sense for a library dependency of the GNOME desktop? It would be nice if we could come up with a mechanism that would allow us to clearly ship these interfaces as "Do not use", but still provide header files and other interfaces so that people who understand the risks can do so. Perhaps a good example to discuss is libegg. This highly unstable library contains GTK+ widgets that haven't matured enough to go into GTK+. We currently consider it "Volatile" and ship the header files. Since we know it is highly volatile, perhaps we should make it "Private" and not ship header files, as has been suggested for libgweather. I *assure* you that if we do this, many users out there who build programs which depend on libegg will start screaming. People who build programs that depend on libegg know that they occasionally need to recompile their code - at least until the widgets they need migrate into GTK+ proper. >> All interfaces that are Volatile or higher need to be supported. > > No. That's a product decision. I guess I don't see the value of having interface stability if we don't make any real effort to make sure things work, beyond having stable interfaces. But ARC doesn't always make sense to me. Brian
