Stephen Lau wrote:
> Shawn Walker wrote:
>> So a project to ensure it works great on OpenSolaris and an ARC
>> integration request by a community member could indeed succeed?
>> Correct?
>>
>>
> That covers the resources involved with just the integration, and IMHO -
> that would be sufficient to get it initially integrated. The trickier
> part involves making Sun-supported components dependent upon a community
> component. Sun can't really claim corporate-support (as opposed to
> community support) for a component unless it can support all the
> dependencies up the chain, like they claim to for PostgreSQL.
I think a lot of things have gotten conflated in internal discussions,
which led to the theory that 'support' is the problem. I think that
"support" and "commitment level" have been unfortunately conflated.
Let me attempt to explain. :)
1) When we build software in Solaris or OpenSolaris, the arbiter of
what interfaces we're allowed to use is the ARC. That is, certain
projects provide interfaces, and declare a stability level. If
that stability level is less than Committed, restrictions are placed
on its use.
2) This has *nothing* to do with whether Sun (or anyone else) Supports
the underlying interfaces projects choose to use. That is Good. :)
3) Updating or changing software components is done based on the
ARC stability level of the interfaces provided.
Let's pretend we're talking about SMF using SQLite. Sun doesn't
support SQLite today. It supports SMF. If a paying customer
escalates an SMF bug that is diagnosed to actually be an underlying
bug in SQLite (which, btw, has never happened), it doesn't matter.
Sun must fix the bug (or risk not meeting a support contract).
Sun can choose to fix the bug by:
- evaluating that a newer version of SQLite fixes the bug and
upgrading the version,
- creating their own patch to SQLite (if the license allows), and
privately using a patched version, or
- working around the bug in SQLite in higher level software.
What constrains the solution choice here beyond the technical
realities? Only the ARC commitment level. If updating SQLite
will violate the ARC stability level of the interfaces provided,
the SMF team couldn't do that.
4) The CTeam or code reviewers are likely to ask you to coordinate
more extensive testing if you're updating a component which other
system critical components use. Higher Stability levels also tend
to suggest more compatibility testing is required.
5) ARC doesn't like 'duplicate functionality'.
Since we're talking about existing consumers like SMF and now
Duckwater... some people might be under the confused impression
that existing consumers would need to be updated to phase out their
private copy of SQLite before ARC would allow it to be integrated.
As you've probably guessed, my strong belief is that's not true.
This case actually doesn't fall afoul of the 'duplicate
functionality' ARC concern.
SMF uses a private copy of SQLite that is Version 2. Everyone I know
of who wants SQLite is clamoring for a *recent* SQLite, which means
Version 3. SQLite Version 2 is both file format and API incompatible
with Version 3. That's why they're a *major* revision apart for
the compatibilitiy-conscious SQLite development community. The
SQLite community intended for Version 2 and Version 3 to be able to
run side-by-side so that existing Version 2 consumers weren't left
out in the cold.
Moving existing internal consumers would be a *major* amount of work
with no user-visible benefit. Existing internal consumers manage
their own Private copy of SQLite Version 2. They can move towards
Version 3 on their own schedule -- removing the private Version 2
shouldn't be a prerequisite for including Version 3.
There should be absolutely no problem with providing a Version 3
SQLite. It doesn't provide duplicate functionality, so the existing
consumers' use of the private copy doesn't have to be phased out.
If someone was talking about creating a Committed SQLite Version 2,
we'd be having a slightly different discussion. But, nobody that
I know of wants Version 2.
The big thing when attempting to prepare something for SQLite for
integration will be the stability level. As everyone knows, SQLite is
useful, so lots of folks will probably want to build on it. PSARC will
likely take note of that and would prefer to see it at a higher
stability level. That's more work, but means that folks can build on
what you've integrated. And, since the SQLite community is very
sensitive about stability, it makes sense to try to ARC it at somewhere
closer to Committed. Bringing this component which people won't want to
use standalone through ARC as Volatile is likely to be met with derision
and possibly denial. (I don't speak for ARC, though. I could be wrong.)
As I said internally the last time this discussion rolled through --
integrating SQLite into either SFW consolidation so that it was bundled
with Solaris and other OpenSolaris based distributions by default would
be a win for all of our customers. The SMF use of Version 2 doesn't
stand in the way of that worthy goal, but SMF won't be an early adopter
because of the significant cost involved in upgrading to Version 3.
But, having a publicly consumable Version 3 SQLite would still be a big
win, and I support any effort to make it happen.
liane
