LSARC/2008/059 - SQLite

[Nicolas Williams]

On Fri, Feb 01, 2008 at 06:00:32PM -0600, Brian Cameron wrote:
> James:
> >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.

Yes, yes it does always make sense to ... just because ... (and for
other reasons too).  We ship multiple versions of certain things, and
even announce our intention to when we expect incompatible change ahead
of time.

> >>Our thinking in making the interfaces Volatile was because we didn't
> >>want to make it so difficult for others to consider using the
> >>interfaces, if they are okay with the risks associated with "Volatile".
> >
> >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.

Volatile is hard to use because it means you can break on patch, this is
true regardless of whether it ever happens.

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

Uncommitted or Committed wouldn't mean we fix everything.  It would mean
that in the event of incompatible SQLite releases we'll either:

 - ship multiple versions, without removing the old ones until a
   suitable release boundary

 - not ship new versions

 - fix the incompatibility ourselves

What's so difficult about this?  Particularly when we know the
likelihood of this is zero?

> >If that's the case, then what violence are we doing to our other
> >stability promises?  What are customers to believe?
> 
> Customers who need stability probably should stick with the interfaces
> that are Committed/Uncommitted.  If SQLite is not marked as stable,
> then there are other database options on Solaris which might be a better
> choice.

SQLite is the premier open source *embedded* DB.  It has a different
target audience than the other DBs that we ship.

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

But we're making a distribution where we add value.

> >>If the database team were willing to own SQLite, I would 100% agree
> >>with you that the interfaces should have a higher stability level.
> >
> >It's the conflation of ownership and funding with stability level that
> >I find distasteful in this project.  It shouldn't be this way, and it
> >ends up shoving cost out onto the users -- either they can't use a
> >perfectly good available tool (and must invest in another one with
> >better stability and support), or they have to negotiate a contract
> >for special use and worry that they're living on borrowed time.
> 
> The two choices you suggest aren't the only choices possible.  In fact,
> most 3rd parties link in their own copies of non-committed interfaces
> when they have concerns about stability.

Which means we're not adding value.