LSARC/2008/059 - SQLite

[Nicolas Williams]

On Fri, Feb 01, 2008 at 03:22:39PM -0600, Brian Cameron wrote:
> 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.

I think checking the notes should be sufficient here.  But if the
ARC/c-team would insist on a home-grown testsuite, *then* the work of
doing better than Volatile becomes prohibitive.

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

The whole point of Indiana is to include things like SQLite that
developers *expect* to be included in an OS.  Volatile is bad enough
from that point of view.  Private would be a waste of our time.

I think I'm at the point where I'd be willing to take ownership of
SQLite here if it would make any difference.

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

Gaaa.  What'd be the point?

Nico
--