FOSS and Interface Taxonomy levels

[Brian Cameron]

Nicolas:

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

Using GStreamer as an example, this isn't really practical.  There
are many GStreamer programs that are useful to some people, but
are simply not up to the quality levels that are required to ship
with Solaris directly.

Examples include jokosher, elisa, and pitivi.  People who need to
do multi-track recording, video editing, etc. like to use these
programs, but currently have to put up with the fact that these
programs crash if you use certain features, etc.  Some media
programs only work with OSS, which currently isn't integrated in
Solaris, so people who want to use these programs need to install
the OSS pre-release.  Some assembly required is the state of
affairs with media in Solaris at the moment, I'm afraid.

There will likely always be bleeding edge software that some people
(like developers) might want to play with.  It just isn't practical
to assume that we can ship all free software programs that use an
interface.

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

:)

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

We currently do this.  Most of the JDS section 3 manpages point to HTML
docs in /usr/share/gtk-doc/html.

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

I thought manpages were how we communicate the interface stability
level to the end-user.  How does the user know the stability level
if the manpage doesn't have an ATTRIBUTES section?

>> "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 :/

When Sun RIF'ed the JDS docs team, it was a real pain.

Perhaps a better example is the efforts the JDS team has made to move
daemons and non-user-executables from /usr/bin to /usr/lib.  I think
I alone have probably spent 2 months of my life doing this.  For
example, I was the one who ported all the gnome-applets from /usr/bin
to /usr/lib.  What a pain!  And we still have some daemons in /usr/bin
(gnome-keyring-daemon).  It seems no matter how much work you do, there
is always more to do.

I guess I just don't agree that doing things right is not much work.

Brian