LSARC/2008/059 - SQLite

[John Plocher]

Brian Cameron wrote:
> 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.

Yet they *will* need to re-validate and re-certify their stuff *EVERY*
time you release a patch, upgrade or new version, just to prove that
things that /could/ break actually didn't.  With something stronger,
they wouldn't.

If you have 10 teams that reuse your stuff, this translates into
an order of magnitude more work if you make it Volatile; /you/
may save some effort, but your local optimization ends up costing
the company 10 times as much.

I think I agree with Nicolas and DrH - statically link firefox
with SQLite and don't attempt to make a shared version that you
are unwilling or unable to properly support for general use.

> If I were a customer, I would understand that Volatile means that
> Sun isn't going to support me if I have problems.  

Braap.  That is not at all what Volatile means or implies.  Promulgating
misunderstandings based on misinformation seems to be a bad thing
to do.

Volatile means that we can and will make incompatible changes to
these interfaces in patches if we so choose.  Period.  It says
nothing at all about support levels or what we will do if you
file a bug with us.

> In my experience working with ARC, ARC seems to promote keeping
> up-to-date with the FOSS community as a higher priority than worrying
> about FOSS interface stability levels.  

E_Chicken_and_egg.  The Project teams bringing in FOSS don't seem
to be able to deal with the underlying tension between "I want to use
FOSS-thing-V-x.y.z", "customers want to have FOSS-thing-V-latest" and
"customers sometimes want what you do, but a different "x.y.z"...


> In the past when I have suggested that
> ARC get more involved with external communities to promote better
> interface stability within those projects, the responses seem to be
> somewhere between ambivalent and negative.

That is because you are suggesting a syntax error.
Instead, with the exact same result, we should get project team members
who are involved with external communities to become ARC members.


> It depends what our
> priorities are.  

The interface taxonomy is simply a mechanism to communicate long term
expectations concerning the evolutionary stability of interfaces.

The choices that a team makes about its support policies are a
different thing entirely.  Apples and Oranges, really.

   -John