FOSS and Interface Taxonomy levels

[Nicolas Williams]

On Wed, Mar 05, 2008 at 03:49:03PM -0600, Brian Cameron wrote:
> 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.

The i-team (and others) can help here, but it helps if the i-team's
attitude isn't "I won't do it, so don't ask me to."

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

Alternative take: most users would prefer not to have to build anything
-- the apps they want should be available pre-built, either on install
or via an online package repository.

Then the stability of the libraries becomes relevant mostly only to
non-open source third party apps.

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

I agree that GStreamer is not a good example of an API to go make
Uncommitted.  See?  We can reach agreement on suitable interface
stabilities.  The ARC isn't asking that everything be Uncommitted or
better.

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

This argues for shipping stub manpages pointing to HTML docs in
/usr/share/doc/...

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

Probably.  But that's less of an architectural issue.

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

I know.

> Want to help us write manpages?  :)

No :/

Nico
--