James: >> It sounds like work is saved for people who want to use the interfaces. >> Not for the JDS team. :) Verifying that interfaces are stable is more >> work than just checking release notes, after all. > > Not necessarily. I don't think anybody is expecting a byte-by-byte > examination of the changes that go into an imported large project. > > It doesn't happen for Solaris itself, and expecting that out of > someone else doesn't seem right to me.
The JDS team currently does ABI comparison for all of our Committed interfaces. > Instead, you're supposed to verify that (a) the _intent_ is there; > that is, the upstream doesn't actually intend to break things over > time (some other projects gleefully do this; I don't think this one > does), and (b) the bits you import are not expected to have > incompatible changes. > > Everyone fully understands that accidents can and will happen, no > matter what the stability level says. We sometimes break Committed > interfaces by accident. When it happens, someone has to fix it. > (That "someone" is mostly a business decision -- it could be the team > that integrated it, a dedicated support group, the team that found the > problem, or someone else entirely.) > > You don't need to promise to boil away the ocean to see if there might > be rusty nails and other bugs at the bottom. I'm not sure it always makes sense to mark a Solaris interface as Committed or Uncommitted just because an external community has the "intent" for stability. >> Our thinking in making the interfaces Volatile was because we didn't >> want to make it so difficult for others to consider using the >> interfaces, if they are okay with the risks associated with "Volatile". > > But Volatile *IS* hard to use. It says that the interfaces will > change without notice, possibly breaking you in a patch. You'd have > to be either working on a trivial home directory experiment or just > daft to put up with that sort of "commitment." Volatile is only hard to use if the problem you describe actually happens. If the interfaces never break because the external community has good ABI compatibility, then users depending on that interface will probably not notice that the interface is Volatile. > Or you (the consumer) may well be assuming a higher stability level. > In other words, you know that SQLite is stable, and Sun has applied > the wrong stability level. You chuckle at the "Volatile" label and > plow on. If I were a customer, I would understand that Volatile means that Sun isn't going to support me if I have problems. If I know the SQLite community will take care of me, then I might be agreeable to not worrying about the lack of Sun support. > If that's the case, then what violence are we doing to our other > stability promises? What are customers to believe? Customers who need stability probably should stick with the interfaces that are Committed/Uncommitted. If SQLite is not marked as stable, then there are other database options on Solaris which might be a better choice. Most people who use free software interfaces, however, aren't looking for this level of stability. >> If the database team were willing to own SQLite, I would 100% agree >> with you that the interfaces should have a higher stability level. > > It's the conflation of ownership and funding with stability level that > I find distasteful in this project. It shouldn't be this way, and it > ends up shoving cost out onto the users -- either they can't use a > perfectly good available tool (and must invest in another one with > better stability and support), or they have to negotiate a contract > for special use and worry that they're living on borrowed time. The two choices you suggest aren't the only choices possible. In fact, most 3rd parties link in their own copies of non-committed interfaces when they have concerns about stability. >> That's quite a metaphor. I have also expressed concern at the fact >> that 99% of the external FOSS interfaces were are brining into >> Solaris are using the Volatile classification, however I am not sure >> it is as serious as life and death, as you suggest. I'm also not >> sure SQLite should be the poster child to resolve this FOSS >> Volatile issue. > > What you're describing sounds like the "External" fiasco that we've > tried so hard to steer away from. It sounds to me like we're not > being too successful at it. 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. This is my understanding why there are so many FOSS Volatile interfaces. Perhaps that is changing? 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. > When we know we're abusing the taxonomy, we should stop. Even if > we're surrounded by others who are busily digging the same hole ever > deeper. I'm not sure that we are abusing the taxonomy. It depends what our priorities are. Are we working to build an ironclad stable software platform based on FOSS components, or are we trying to provide a development platform that is competitive with Linux, or what? How we classify FOSS interfaces should depend on what we are trying to achieve. >> More realistically, we probably need to be at least as good as our >> competition (e.g. Linux). If the interfaces are really Stable via >> the external project, as you suggest, then our interface classification >> probably does not matter, aside from affecting things like the amount of >> our internal paperwork. > > Our recorded stability level is what we offer to our customers and to > our internal project teams. > > If we're not going to bother trying to get that right because we > "know" that it doesn't matter, then the ARC process itself also > doesn't matter. We might as well skip it entirely if we're not going > to make a good-faith attempt at getting it right. > > Waving the "Volatile" flag at everything makes a mockery of the > intended process, every bit as much as External once did. I have raised that concern myself. However, I don't agree with you that it makes Solaris or ARC a mockery. It just means that users who need Stability are limited from using a lot of FOSS components. I'm not sure that is necessarily a problem. It depends on what we are trying to achieve. Brian
