FOSS and Interface Taxonomy levels

[Brian Cameron]

Nicolas:

> Given the current ARC "bias" towards interface stability (which, correct
> me if I'm wrong, is a business mandated bias) then the best approach is
> to measure and budget for the cost of FOSS integration.  That's a
> business issue.  Alternatives include changing the ARC bias.

In my opinion, ARC seems to sometimes have difficulty determining which
interfaces are really important in terms of stability.  There seems to
be an assumption that users won't be able to cope with some interfaces
being Volatile.  So there seems to be a black and white attitude where
you either make something stable or you don't ship it.

In some cases, providing interfaces for "developer use only" allows
people to use Solaris as a developer platform, and be more involved
with helping to stability interfaces.  Developers will migrate to
Linux if they find needed or desired developer interfaces there.

Within the GNOME stack there are many examples.  GStreamer, for
example.  Is it better to allow people to download and build
applications which use GStreamer with the risk that the Volatile
interfaces may break (and the users may need to recompile), or is
it better to disallow people from building such programs?

I think most users would rather recompile than be prevented from
building the programs they want in the first place.

Now, if there is a real user need for GStreamer to be Uncommitted
(e.g. programs break for which people don't have the source code
and they can't recompile), then making more of an effort to stabalize
the interfaces seems better.

> All I see here are business issues.  For now I think FOSS integrators
> should aim to make relevant interfaces stable (e.g., executable paths
> and some but not all options), either by putting in the work to do so
> (or promising to, effectively binding whoever takes over their duties,
> if anyone does) or by noting the risk that multiple versions of such
> FOSS will need to be shipped (also risking DLL hell).

I think this is a good idea to strive towards, but I don't think it
is a good rule that applies to all cases.  Or perhaps I am just
saying that it may be non-obvious which interfaces are truly
"relevant".

> [My experience with SQLite3.x is that though it will have taken
> significantly more effort to "Do it Right" (tm) than I'd hoped, the
> integration effort will not have been prohibitively expensive, not
> nearly.  SQLite3.x comes with a great history of and commitment to
> interface stability, but it also comes with some, er, weird attitudes
> towards dynamic linking that betray lack of confidence in the
> community's commitment to interface stability.  This has led to my
> spending far more effort than I'd wanted on integrating into the SFW
> consolidation.  Other FOSS will, no doubt, come with its own odd
> surprises.]

 From our experience working with the JDS stack, we have invested a
great deal of time and effort to try and "Do it Right" as much as
possible.  I would say that, in general, the work is non-trivial
and time-consuming.

For one example, we need to convert all JDS manpages to SGML format and
typically rewrite them to make them conform to Sun's manpage style
guide.  This alone is a significant amount of work, since the community
manpages are a moving target and we try to review and update 450+
manpages as needed every time we integrate into Nevada.  Some releases
we do a better job than others.  Even though we spend a lot of time and
effort on this, we still ship about 100 programs in /usr/bin without
manpages.

I understand other teams (such as Xserver manpages) don't even bother
with following Sun's manpage style guides.  I'd bet a lot of stuff
in SFW doesn't either.

"Doing Things Right" can be a lot of work, and extends far beyond
just making the code build and link properly.  That's the easy part.
Want to help us write manpages?  :)

Brian