[Fwd: Re: GNOME Namespace Management - ARC & GNOME]

[Brian Cameron <Brian Cameron Sun COM>]

Mike:

> Here are some comments on the document.
>
> Firstly, I see one issue with the Sun classifications, namely that
> "Standard" and "Stable" seem to be slightly at odds with each other. There
> has been mass breakage in the Linux world before when a widely
> used interface that was supposed to implement a public standard but didn't
> was changed incompatibly to be more standards compliant.

[ examples clipped ]

Since Sun provides a guarantee that applications will not break on
Solaris, Sun will work with customers to keep applications working if
at all possible.  When working with internal applications, Sun has
some control to ensure that applications make things work appropriately
in a backwards compatible fashion.  However, when working with a project
like GNOME, Sun has only some influence.  This influence is somewhat
hampered by the fact that the GNOME community itself does not make
backwards compatibility a priority (at least not to the same degree
as Sun).

Note that Sun does not provide the same guarantee for Sun's Linux
offerings, only Solaris, so breakages in the Linux kernel do not cause
Sun the same sort of issues that breakages in Solaris cause.  In
Solaris, there are only a few components that we depend upon that
are not controlled internally.  One example is GNOME.  I think Sun
would like to work more closely with the GNOME community to better
ensure that standards are defined and followed - with the idea that
this will reduce the liklihood of such breakages.

One thing that makes GNOME a little easier to deal with is that
most Sun customers do not build their own applications using the
GTK+/GNOME stack.  Further, Sun discourages customers from
depending on (linking against, for example) the GTK+/GNOME stack
since the GNOME community doesn't provide strong enough stability
guarantees.  Since Sun itself provides most of the core GNOME
applications with Solaris, most breakages that have occurred to
date have not been noticed by customers.  Still, there is the
risk that a customer will start depending on them and will want
Sun to fix bugs that cause their applications to  break when
they upgrade to a newer version of GNOME.  Therefore, Sun is
wanting to work more closely with the community to try and
better ensure that such breakages are identified, fixed, and
proactively prevented.

 > When Sun finds that an interface which is believed to be standards
 > compliant is in fact not so, which takes priority - compliance or
 > application compatibility? How is this reflected in the ARC labels?

This is something that ARC is currently struggling with.  The GNOME
stack is perhaps the most significant aspect of Solaris that is not
developed internally at Sun.  Other exceptions include projects like
Mozilla and the Xserver.  However, most of these projects take
stability more seriously than the GNOME project and make more of an
effort to follow standards/specifications that are well developed by
organizations like w3c and X.org.  Perhaps freedesktop.org will
become a standards body with the same sort of clout as w3c or X.org,
but that will probably take time, and more community dedication towards
defining/following standards.

So the ARC community has been trying to define new stability levels
to better reflect situations where Sun works with an external body,
like GNOME, where stability levels are more difficult to define or
are poorly specified.

> Second thing, on what sort of timescale do you think ARC will produce
> similar documents for other interfaces? Filesystem interfaces are
> important, in fact a customer recently sent the company I work for a patch
> to deal with s/gnome-moz-remote/gnome-open/, but I feel they are generally
> quite stable. The biggest problems seem to be cultural.

At the moment, I think Sun is focusing on seeing what improvements can
be made with the GNOME community.  If this is an area where the GNOME
community and Sun can engage, then I think it is more likely that Sun
will work more closely with GNOME, and other Free Software projects in
the future.  If we find that the two communities do not engage well, it
might set things back.

Although the file system interfaces that GNOME depends on are somewhat
stable, they are poorly defined and are not well organized.  Sun feels
that proper definition and good organization are part of what makes
interfaces stable.  So Sun would like to see improvements in these
areas before Sun would agree that they are generally stable.

> Here are some comments on the file path table:
>
> /etc/gimp, External: how is this directory which is internal to an image
> editor considered a stable interface?

The gimp system-wide rc files are stored here.  Changes that a system
administrator makes to such files to affect the behavior of gimp
shouldn't break from release-to-release.  Or do you disagree?

> /etc/gconf, External: the data here is dependent on the backend in use, I
> don't think it's smart to imply apps can rummage around in here directly.
> The only GConf API that I'm aware of is exported by the shared library API
> and the gconftool program.

User applications should be able to integrate their gconf data to these
file locations and expect them to work from release to release.

> /usr/share/fonts, External: yes I agree with this label, but it's not the
> GNOME fonts directory, it's a default setting in the fontconfig config
> file. It is a de-facto standard on modern fontconfig aware systems but I
> don't think there are any formal guarantees that it's actually used: this
> perhaps needs fixing.

Thanks for the better description.  I'll update my table.

> /usr/share/gnome-background-properties: I don't have this directory on FC3 ...

This is Sun specific.  Since the ARC process is reviewing the Sun delivery,
we are reviewing the files that we install on Sun.  Most of the information
in the table is of general community interest, but this is an exception.  I'll
update the table to make it more clear that this is Sun-specific.

> /usr/share/gtk-doc, External: AFAIK there are no guarantees that this
> directory is a part of the GNOME developer platform exported interface but
> it probably should be (pending a move?)

It is the directory on Solaris where we let users know that they can install
gtk-doc's that they wish to generate.

> ~/.gtkrc, External: I'm not 100% sure this is a guaranteed stable
> interface though perhaps it should be if not.

Sun considers glib, pango, gtk and libglade to be the GNOME modules that it
supports with the highest level of guarantee against breakage.  Since this
is a GTK+ interface, we have to support it more than we support other
parts of GNOME.

--

Brian