Nicolas Williams writes:
> On Wed, Jan 30, 2008 at 09:08:40AM -0500, James Carlson wrote:
> > In that case, we should make our stability attributes match the ones
> > advertised by the software authors. Use "Uncommitted" or better for
> > the things that are in fact stable, and "Volatile" and "Obsolete" for
> > the experimental and deprecated parts. Just pass the upstream
> > guarantees to the downstream users.
>
> I agree in this specific case, but should we generally do this where
> possible?
>
> The upstream community may have an interface stability taxonomy that is
> roughly compatible with ours, and maybe even a similar release binding
> taxonomy, but it's unlikely that their releases will be timed at all
> with ours.
Unless that upstream is somehow committing directly to the local
workspaces used to build the bits that appear in our releases, I don't
see how that's a problem.
> Or is that not a concern because if the upstream community makes "major"
> releases then we can just ship multiple versions of it in the next
> micro/patch release of Solaris (or OpenSolaris release vehicles)?
> Multiple versions of libraries can be problematic, after all, though I
> believe in most cases there's always reasonable guidance that can be
> given to avoid DLL hell.
In extreme cases, and where it was felt to be necessary, we've done
exactly that.
> Is there precedent to set here?
I honestly don't see anything new here. These issues come up from
time to time, and the answers are roughly the same.
A good example of a similar case was with BIND (aka "named"). The
submitter originally wanted to make it all External ("Volatile") on
the theory that it's open source, we don't control it, we don't know
what it is, and so on.
It turns out that none of this was in fact true, and the desire to do
this was just an attempt to avoid a bit of necessary work. The
upstream supplier *DID* in fact separate the interfaces neatly into
"we won't change," "we might change," and "we're certain to change"
classes, and it was easy to map those into appropriate guarantees for
Sun customers -- meaning, interface stability levels.
Slapping on the "Volatile" label looks like an easy fix, but it really
just pushes the work onto somebody else, and that's not quite fair.
> > (It doesn't matter whether the documentation is in man page format, so
> > I'm not sure I understand your parenthetic comment. Care to
> > elaborate?)
>
> (I was worried that using anything other than Volatile might mean that
> the i-team would have to provide manpages, but I don't think that'd be
> the case. Can you confirm?)
The official Solaris documentation is in man pages, but we've
certainly made many exceptions in the past where the upstream provider
doesn't support this. A good example of it was PKCS#11.
--
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
