Brian Cameron writes:
> 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.
There are likely to be support implications for stability levels, but
they're not necessarily obvious.
You're right that undocumented (private) interfaces are generally not
"supported for customer use." But, then, in architectural terms,
they're not available for customer use, either, so that's not quite
the interesting case.
The interesting cases come with the public stability levels, Volatile,
Uncommitted, and Committed. I'm intentionally arguing that there is
no necessary relationship between any of the support levels that might
be offered for those interfaces and the stability level. "Volatile"
doesn't mean "we won't help you if you have trouble." It means "this
will change incompatibly, possibly in a patch, and anything built on
it may break." The two are very different statements.
> 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?
That's one possible answer.
Another is to pursue the problem outside of the ARC. Tell the
business team that you have a set of things that customers can in fact
use, and you want to let them use, but you're not willing to take
customer calls on. Explain where those things are and how a customer
could identify them and avoid them if necessary.
I don't see how this is really an architectural problem at all.
> 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?
No, it doesn't. But that's a single instance; there may be others
that match those better.
I'd assert two things:
1. If we know something about how libgweather is likely to evolve
in the future, then that should dictate the stability level we
advertise. If it's going to change rapidly and chaoticly, then
Volatile with warnings is appropriate. If it has well-known
change (though perhaps not identical to our terminology, but at
least documented and versioned), then something higher would be
better.
2. If we're just not going to take support calls when someone uses
a documented interface, then we need to mark it appropriately.
I think it's between you, the business team, and the support
folks who will end up getting those (possibly angry) customer
calls to figure out what that statement should say.
> 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.
There's a dangerous slope in there, and it goes by the name
"autoconf." Far too many people end up using things that they didn't
realize were "unsupported."
> 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.
Sounds fine. But that's architecture *NOT SUPPORT*.
> >> 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.
The stability levels (again) tell you how and when things will change.
That's what they do. They don't solve business problems. They don't
tell you whether the vendor is reliable. They don't tell you whether
something is secure. They don't tell you about performance. They say
nothing at all about licensing or IPR restrictions. And they say
nothing about whether there's anyone who cares about the bug reports.
Those are business problems. In the past, we've said that if
something is shipped with Solaris, it gets a certain default level of
support because it has Sun's imprimatur on it, regardless of where we
got the bits or what we may think of them privately. I hope we still
do that in the future ... but, again, not architecture at all.
--
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
