John: > 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.
In the past, the JDS team has upgraded interfaces from Volatile to Committed when we have gotten enough contracts that it becomes more efficient to manage this way, for exactly the reasons you suggest. It seems that to bring a new, external interface in as Volatile and then upgrade them to more stable classifications when there are clear users is not out-of-line with the evolutionary nature of how ARC is supposed to work. I am not aware of 10 teams outside of the JDS consolidation waiting in line to use SQLite. But, based on this discussion, I guess people anticipate these SQLite interfaces will be heavily depended upon and are, therefore, deserving this special attention and discussion. > 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. Let's leave it up to the project team to decide whether to make the interfaces private or to properly support them with a higher interface level. >> 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. Thanks for correcting my misunderstanding. You are, of course, right. That said, my point was that 3rd parties could statically link in their own copies of SQLite if the one we ship is Volatile and the 3rd party requires stability. I wasn't suggesting this is ideal. I was just trying to point out that how we classify SQLite doesn't restrict our users to using our version. >> 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"... Whether we say it is the Project Team's fault or ARC's fault is just finger pointing, in my opinion. I do agree it is a chicken-and-egg problem, though. >> 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. Agreed. That would really help. Perhaps as we move towards a more OpenSolaris-based world, more FOSS people will get involved. >> It depends what our >> priorities are. > > The interface taxonomy is simply a mechanism to communicate long term > expectations concerning the evolutionary stability of interfaces. Which is probably why we have so many Volatile FOSS interfaces in Solaris. Brian
