LSARC/2008/059 - SQLite

[James Carlson]

Brian Cameron writes:
> James:
> > It doesn't happen for Solaris itself, and expecting that out of
> > someone else doesn't seem right to me.
> 
> The JDS team currently does ABI comparison for all of our Committed
> interfaces.

Good to hear.

> > You don't need to promise to boil away the ocean to see if there might
> > be rusty nails and other bugs at the bottom.
> 
> I'm not sure it always makes sense to mark a Solaris interface as
> Committed or Uncommitted just because an external community has the
> "intent" for stability.

So what do you make of the Sun projects that use these same commitment
levels?  Would you expect a Sun team to disavow support because
they're publishing Volatile interfaces?  Or that we provide some sort
of special premium level of support for Committed interfaces?

In fact, the two are just plain unrelated.  The stability level
communicates intent: it tells people when we will likely break things,
and when we intend not to do so.  We can't possibly prevent all human
mistakes, and we can't predict the future, so it's not possible for us
to say anything more than *intent."

Whether and how a customer gets support is a separate business
decision and a matter of appropriate documentation.  It could be
through some Sun-provided on-site team.  It could be an on-demand
service.  It could be a third party with whom Sun contracts.  It could
even be some open source forum.  Perhaps even "no support at all."

I'm not buying the argument that "Volatile" can or should mean "we
won't try very hard to support this."  The ARC doesn't make or
evaluate support commitments.

> > But Volatile *IS* hard to use.  It says that the interfaces will
> > change without notice, possibly breaking you in a patch.  You'd have
> > to be either working on a trivial home directory experiment or just
> > daft to put up with that sort of "commitment."
> 
> Volatile is only hard to use if the problem you describe actually
> happens.  If the interfaces never break because the external community
> has good ABI compatibility, then users depending on that interface
> will probably not notice that the interface is Volatile.

In that case, they never were actually Volatile, and our documentation
and the ARC case that described the project were wrong.  I don't think
that getting stability levels wrong in either direction is desirable
-- making them too stable means that changes are painful for the
single interface owner, but making them too unstable means that usage
is painful for the many interface consumers.  In fact, I'd expect that
making them too unstable is higher cost in the long run, and as long
as we're not optimizing for one group.

> > Or you (the consumer) may well be assuming a higher stability level.
> > In other words, you know that SQLite is stable, and Sun has applied
> > the wrong stability level.  You chuckle at the "Volatile" label and
> > plow on.
> 
> If I were a customer, I would understand that Volatile means that
> Sun isn't going to support me if I have problems.  If I know the
> SQLite community will take care of me, then I might be agreeable
> to not worrying about the lack of Sun support.

That doesn't make sense here.  Sun is providing the SQLite packages.
There's no way that community can "take care of" anybody; it doesn't
produce the signed SUNW* packages or patches.  Sun itself will have to
do that.

If I get bits from the external community, I expect the community (or
my own internal team) to support those bits.  If I get bits from Sun,
I don't care a whit how those bits came into Sun's possession or why
Sun decided to ship them to me -- I care only that Sun's imprimatur is
on the distribution medium, and as a customer I think Sun needs to
support its product.

It's likely true that the coding work involved in supporting the
product is the community's problem.  That's Sun's business problem to
work out, and not an architectural stability issue.

> Most people who use free software interfaces, however, aren't looking
> for this level of stability.

I think that's a mistake.  Nobody likes breakage, particularly in
patches, and even with free software.

I've yet to run into someone who was even slightly thrilled to find
that something stopped working right after an upgrade.

> > What you're describing sounds like the "External" fiasco that we've
> > tried so hard to steer away from.  It sounds to me like we're not
> > being too successful at it.
> 
> In my experience working with ARC, ARC seems to promote keeping
> up-to-date with the FOSS community as a higher priority than worrying
> about FOSS interface stability levels.  This is my understanding why
> there are so many FOSS Volatile interfaces.

Keeping up-to-date doesn't mean you have to be Volatile as well.

The two aren't necessarily related.

> Perhaps that is changing?  In the past when I have suggested that
> ARC get more involved with external communities to promote better
> interface stability within those projects, the responses seem to be
> somewhere between ambivalent and negative.

I'm not sure how the OpenSolaris architectural review mechanism works
for some non-OpenSolaris project.  If those teams wanted to do so, I
don't see a problem with those folks deciding to participate in
OpenSolaris and getting their reviews here -- that'd certainly work --
but reaching out and saying in effect "we'd like to tell you how to
produce stable software" seems quite strange to me.

I don't think this ARC is the only way to produce stable software, or
that we're the only font of architectural information.  I think it's
entirely possible for other software projects to do a decent job of
engineering without necessarily needing (or even wanting) our help to
do it.

Thus, in my opinion, equating all external efforts that produce
essentially equivalent results with our lowest possible stability
level does them (and us) a substantial disservice.  They just can't be
that bad, and we can't possibly be that good.

> > When we know we're abusing the taxonomy, we should stop.  Even if
> > we're surrounded by others who are busily digging the same hole ever
> > deeper.
> 
> I'm not sure that we are abusing the taxonomy.  It depends what our
> priorities are.  Are we working to build an ironclad stable software
> platform based on FOSS components, or are we trying to provide a
> development platform that is competitive with Linux, or what?  How
> we classify FOSS interfaces should depend on what we are trying to
> achieve.

We're trying to build a system.  A big one.  Doing that requires
software architecture.

Part of software architecture is analyzing the dependencies and
stability levels *advertised* by the components.  If Jane says she'll
break her commitments in the next patch, but Sarah says she's building
on top of Jane's work, then we've got a problem.  It matters not
whether Jane promises to provide support, or Sarah says she'll
recompile every other Tuesday.  What matters is finding some way to
stabilize that dependency so that users of the software are not likely
to see the problems.

I don't think anyone here is suggesting that we ought not be
competitive with Linux.  And I agree completely that classifying FOSS
interfaces (and, actually, classifying *ALL* interfaces) should depend
on what we're trying to achieve.

If what we're trying to achieve is software that either breaks
fundamental rules of good design (by depending on things that change
in uncoordinated ways) or is useless once customers look behind the
glossy marketing materials (it has SQLite ... but Sun promises to
break it in a patch), then, by all means, lump it all in as "Volatile"
and don't worry about it.  I'd actually advocate skipping
architectural review entirely if that's what we want to achieve, as
it's a large expense with zero return for merely Volatile bits.

That's what was wrong with the "External" mess, and that's what we
were trying to avoid repeating.  FOSS != External and FOSS !=
Volatile.

> > Waving the "Volatile" flag at everything makes a mockery of the
> > intended process, every bit as much as External once did.
> 
> I have raised that concern myself.  However, I don't agree with you
> that it makes Solaris or ARC a mockery.  It just means that users who
> need Stability are limited from using a lot of FOSS components.  I'm
> not sure that is necessarily a problem.  It depends on what we are
> trying to achieve.

I am sure it's a problem.  Project teams cannot consistently come to
the ARC and say (in effect) "we're at the top of the food chain; we
depend on everyone, but nobody can ever depend on us, so we needn't
promise anything to anyone."  That's architectural death.

Brian Cameron writes:
> In the GNOME Project, the ORBIT2 and bonobo interfaces are stable and a
> part of the GNOME Platform, and covered under ABI guarantees.  In our
> Solaris distro they are "Volatile".
> 
> I can point you towards many references where the GNOME community
> discourages people from using these interfaces, and the GNOME community
> has announced that they will, someday, deprecate the interfaces (though
> they plan to continue supporting them in a stable fashion).

That sounds like "Obsolete Committed" to me.  It's an interface
they're not going to change, but that nobody new should be using
because they're planning to remove them eventually in the future.

Yes, an interface can be declared "Obsolete" when it's first
published.

(I seriously doubt that there are significant cases in the GNOME or
any other open source community that fail to fit nicely in the
existing taxonomy.  If there are, we'd certainly make room for them,
but it's not as if those stability levels were developed in a
technical vacuum.)

> In free software communities, even when you have the buy-in the of
> maintainer, I would never describe the risk as zero.

No change we ever make has zero risk.

Brian Cameron writes:
> It seems that to bring a new, external interface in as Volatile and
> then upgrade them to more stable classifications when there are clear
> users is not out-of-line with the evolutionary nature of how ARC is
> supposed to work.

It's not ... but the feedback you're getting is that when we know that
the interface is not as risky as advertised, then we're not doing
favors by claiming it is.

-- 
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