On Wed, Jan 30, 2008 at 11:55:33AM -0500, James Carlson wrote:
> Nicolas Williams writes:
> > On Wed, Jan 30, 2008 at 09:08:40AM -0500, James Carlson wrote:
>
> > Is there precedent to set here?
>
> I honestly don't see anything new here. These issues come up from
> time to time, and the answers are roughly the same.
>
> A good example of a similar case was with BIND (aka "named"). The
> submitter originally wanted to make it all External ("Volatile") on
> the theory that it's open source, we don't control it, we don't know
> what it is, and so on.
>
> It turns out that none of this was in fact true, and the desire to do
> this was just an attempt to avoid a bit of necessary work. The
> upstream supplier *DID* in fact separate the interfaces neatly into
> "we won't change," "we might change," and "we're certain to change"
> classes, and it was easy to map those into appropriate guarantees for
> Sun customers -- meaning, interface stability levels.
>
> Slapping on the "Volatile" label looks like an easy fix, but it really
> just pushes the work onto somebody else, and that's not quite fair.
OK, then IMO we should use Uncommitted or even Committed for much of the
SQLite 3.x CLI and API. We should probably have some warning in the
docs about the possibility of revs where creating *new* databases or
using new features may result in backwards-incompatible database formats
(since that's the sort of incompatibility that's been introduced in the
SQLite 3.x train).
Should we include a static link archive? Or should we exhort developers
to build their own when they want to avoid all possible risk?
(Remember, Dr. Hipp recommends statically linking libsqlite into many
apps.) IMO, yes, even if it means building libsqlite twice during the
SFW consolidation build (I assume it will go into SFW).
I'm not an ARC member, so my requests here can be freely ignored by the
i-team. Feel free to ask them for better-than-Volatile classifications.
> > (I was worried that using anything other than Volatile might mean that
> > the i-team would have to provide manpages, but I don't think that'd be
> > the case. Can you confirm?)
>
> The official Solaris documentation is in man pages, but we've
> certainly made many exceptions in the past where the upstream provider
> doesn't support this. A good example of it was PKCS#11.
Thanks. (BTW, the SQLite HTML docs are also distributed as a tar ball,
and could be shipped in /usr/share; including them is probably a good
idea.)
Nico
--
