LSARC/2008/059 - SQLite

[Brian Cameron]

Nicolas:

> On Fri, Feb 01, 2008 at 02:25:48PM -0600, Brian Cameron wrote:
>> Nicolas:
>>> It would still, however, save work to mark the stable parts of the API
>>> as Uncommitted.
>> What work would be saved, exactly?
> 
> Negotiating contracts, informing contract holders of updates.  The
> trade-off is that it would require checking the release notes of SQLite
> (at least) to see if any Uncommitted interfaces have changed
> incompatibly.

It sounds like work is saved for people who want to use the interfaces.
Not for the JDS team.  :)  Verifying that interfaces are stable is more
work than just checking release notes, after all.

 > In that case, make them either Project or Consolidation Private.
 > That'll result in the most difficulty for other projects, as they'll
 > all need contracts.

This is also an option to consider, since this better fits our
Consolidation needs.  It also allows us to avoid concerns like I18N
support or providing manpages.

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

Note if we make SQLite Consolidation Private, this will mean that
we will likely opt to not distribute CLI, headers, or other
interfaces that other groups or external users would likely want.
I suppose we could provide things like the headers to internal
teams with contracts.

If the database team were willing to own SQLite, I would 100% agree
with you that the interfaces should have a higher stability level.
For the JDS team to include it for JDS consolidation purposes
(e.g. Firefox), I'm not sure our team wants to be responsible for
making these interfaces available to others in an Uncommitted or
Committed fashion.  But it is worth discussing.  Perhaps the JDS
management would be willing to accept a higher stability level
if pressed.

I'd recommend pushing for the database team to own SQLite instead
of our team if we want a higher stability level.  They are the
better team to provide this degree of interface stability.  We
talked with them about this, but they didn't seem to think they had
the resources to do so.  Perhaps they might take over ownership over
time.  For now, the JDS team needs SQLite to make Firefox 3.0 run.

 > Note that we don't review things based on "team" boundaries.  Instead,
 > we review them based on project and consolidation boundaries.  If the
 > plan was to use Volatile interfaces across consolidation boundaries
 > (regardless of which "team" was involved) without a contract, then
 > there's a problem.

Sorry, I meant "consolidation" not "team".

 > Use Volatile only if you really feel you need to ship patches that
 > have intentionally incompatible changes.  It's a loaded weapon aimed
 > squarely at the user.  :-/

That's quite a metaphor.  I have also expressed concern at the fact
that 99% of the external FOSS interfaces were are brining into
Solaris are using the Volatile classification, however I am not sure
it is as serious as life and death, as you suggest.  I'm also not
sure SQLite should be the poster child to resolve this FOSS
Volatile issue.

More realistically, we probably need to be at least as good as our
competition (e.g. Linux).  If the interfaces are really Stable via
the external project, as you suggest, then our interface classification
probably does not matter, aside from affecting things like the amount of
our internal paperwork.

Brian