LSARC/2008/059 - SQLite

[John Plocher]

Brian Cameron wrote:
 > The JDS team does not want other
 > teams to depend on interfaces, then get hit by a bug, and expect
 > the JDS team to fix their bugs for them.

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.

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.

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

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

   -John