LSARC/2008/059 - SQLite

[Brian Cameron]

Nicholas:

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

You use the word "always".

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

Also, strangely, the GNOME community claims a few components are a
part of their Platform even though they do not really have much control
over them.  Examples include external-to-GNOME dependencies such as esd
and audiofile.

Since you say "always", I guess you think such libraries should be
"Uncommitted"?  Perhaps our usage of Volatile to steer people away from
using interfaces that do not have external community support isn't the
best usage of our taxonomy, but I'm interested to hear your thoughts.

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

You are much better at predicting the future than I.  I remember when
I defined the GDM configuration files as Committed.  I thought since I
was the GDM maintainer that I had good reason to expect this wouldn't
change.  Now GDM is being rewritten and I am scrambling to figure out
how this will affect our stability levels moving forward.

In free software communities, even when you have the buy-in the of
maintainer, I would never describe the risk as 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.

Right, I am aware that SQLite has its niche.

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

We need to be clever about how we add value.  I'm not sure, in the big
scheme of things, that the stability level of SQLite is where we should
be focusing our energies to add value in Solaris.  Maybe it is.  I'm
not sure.

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

If it turns out that the end result of this discussion is that the
Firefox team decides to add SQLite as a Consolidation Private interface,
then the only added value is Firefox 3.0.

Brian