LSARC/2008/059 - SQLite

[John Plocher]

Brian Cameron wrote:
> If we are saying that SQLite has a great interface stability track
> record and such use cases, and therefore should not be Volatile, then
> this makes sense to me.  However, if we are saying that all FOSS
> interfaces with an intent to be stable should be Uncommitted or higher,

When we reviewed GNOME way back when, we came to the reasonable
conclusion that most of what was there was poorly characterized, and
thus not ready for prime time Committed status.  This created a tension
because we were going to build a bunch of dependencies on /some/ parts
of it, and those parts really needed to be more stable than Volatile.

As a best practice, when incorporating something large and unknown,
we have found that a good 1st step is to minimize the stability
expectations; thus Joe's good advice to find the 5 to 10 things
in a FOSS component that really need to be Committed, and leave
the rest Volatile.

There are two failure modes here - too little and too much commitment.

I covered "Too little" earlier - Volatile makes it significantly
harder and costlier to depend on a component.

"Too Much" is well illustrated by an early version of BIND,
where the case submitter claimed that /everything/ in the FOSS
deliverable was Committed. Of course, when BINDv(n+1) came out,
it turned out that that was a foolish thing to do - many parts of
BIND.old were in fact obsolete, experimental or otherwise
uncommitted by the BIND community, and the new version changed
or eliminated them.  This put us in a very undesirable situation:

	our customers wanted the new version of BIND, and

	our developers wanted to deliver the new version of BIND, and

	we wanted to deploy the new version of BIND,

	BUT

	we had sprinkled dependencies on those 	"not really committed"
	interfaces throughout our own extended source tree, and couldn't
	easily update them all.

Once we know more about a component, we should be able to
make better guesses at what those committed interfaces should
be.  In cases like SQLite, where there /is/ demonstrated stability
over time AND a commitment by the supplier to value compatibility,
an "everything is Volitile" label fails the "least surprise" test :-)

> ... Sun needs to be careful about what interfaces it
> marks as Committed.  

Absolutely.  Marking too many things as Committed is just the other
end of the pendulum swing as marking too many Volatile.

   -John