LSARC/2008/059 - SQLite

[Brian Cameron]

John:

> If the JDS team is the one integrating the feature, it is already
> in the position of being involved with fixing bugs found.  It sounds
> like you are just trying to make sure that your bugfix expectations
> are:
>     JDS team will fix bugs that impact firefox,
>     other teams will need to provide fixes for bugs that
>     affect them but not firefox,
>     otherwise, you will need to wait until the external
>     community fixes the bug.

The JDS team would likely be willing to help fix bugs that affect
other consolidations, but we would prefer contracts in place so we
can keep track of who is actually using these interfaces.  And so
we can be more proactive in helping evaluate new releases with those
other consolidations before we push updated interfaces into Nevada.

> This is a reasonable thing to say; it just needs to be said in
> a way that doesn't distort/abuse the interface taxonomy.
> 
> The feedback is that this is actually much more stable than you
> imply by using Volatile; we should be reflecting that expectation
> to our customers AND our internal developers.

I am looking forward to hearing how we should do that.

>  > As has been pointed out, there is no reason other teams can't work
>  > directly with the SQLite project to make it work for their needs.
>  > If they have a contract in place with the JDS team, then they can
>  > expect our team to work with them to help avoid problems on upgrade.
> 
> Contract or not, since your team is putting it into Solaris, you
> are already committed to work with them to help avoid problems
> on the upgrade.  Changing Committed to Contracted Volatile doesn't
> actually change the amount and type of work that you already are
> going to need to perform...

Contracts assist our team in knowing which consolidations are depending
on the interface so we can work with them before we upgrade interfaces.
Rather than finding out after their programs break.

>  > For example, we would provide them with pre-release test packages
>  > so they can make sure their project works with the new release
>  > before it goes into Nevada, and work with us to fix any bugs that
>  > might be found.
> 
> You should be doing that anyways, especially if there are
> incompatibilities that need to be managed...

I agree we would be doing that anyways.  However, without a
contract, I am unsure how our team would be aware which other
Consolidations might be using the interfaces.  If we declare the
interfaces as Uncommitted, then other consolidations do not need to
tell the JDS consolidation that they are using the interfaces.  Or
am I wrong?

Would "Contracted Uncommitted" or something convey what we want to
communicate?  Or perhaps we need two stability levels.  The stability
level promised by the external project (which is probably Uncommitted)
versus the stability level for other consolidations (which is probably
Volatile since the JDS team would like contracts)?

Or is there a different mechanism other than contracts to keep track
of who depends on an interface?

Or perhaps, after discussion, the JDS team will agree to make the
interfaces Committed if people really think that is what we should
be pushing for.  Though I think the JDS team will need to consider
how that affects resourcing before we can make that commitment.

Brian