GNOME.org
 

Re: GNOME Namespace Management - ARC & GNOME


Mike/Murray:

I will respond to all of the emails on this topic in this one long
email rather than separately.  Sorry that my emails are so long, I
hope they aren't putting you to sleep.  :)

Mike Hearn said:

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.
That's a shame but understandable. What do you recommend your customers use? Presumably not Java, as that has a similarly spotty record of backwards compatibility. 

At the moment, Sun recommends that Java be used as the development
platform for customers.  As I said before, Sun provides a guarantee
to the customer that their programs that integrate into Solaris
will not break from release-to-release.  Since Java is shipped
with Solaris, this guarantee also applies to programs that users
might build using Java interfaces.

However, this guarantee does not mean that customer's Java 1.x
programs will work with Java 1.y (though that is obviously
the preferred mechanism).  Customers who depend on older versions
of Java might need to have multiple versions of Java installed on
their system in order to have continued support.  Obviously, such
a technique can also be used to provide backwards support for
GNOME.  For example, we ship both the libgnomeprint 1.0 and 1.2
libraries with our GNOME 2.6 to support users who are running
older GNOME 2.0 applications.

In other words, Sun does not require that the latest version of
a program always be backwards compatible.  In situations where
backwards compatibility is broken, shipping multiple versions of
the same development stack (or pieces of the stack) is an
option - as long as such breakages are identified and planned
for in advance.  In other words, Sun's ARC does not disallow
breaking interfaces as long as their is a plan/roadmap in
place for continuing support.

One thing I should highlight is that a big reason why Sun
discourages development with the GNOME stack is because the
Sun GNOME team has not been able to do a sufficient job taking
GNOME through the ARC process.  The GNOME community should
understand that the fault mainly lies within the Sun GNOME
team and not with some big decision makers at Sun who have
some negative attitutes towards GNOME.  If the Sun GNOME team
were able to sufficiently ARC the GNOME stack, I believe that
Sun would be more comfortable with customers making use of
it.

Unfortunately, Sun's project team has been too overwhelmed too
properly follow the ARC process.  Over the past two years, Sun
has wanted the Sun GNOME team to provide and support the GNOME
stack on 3 different architectures (Sparc Solaris, x86 Solaris,
and JDS Linux), to get accessibility working, and to properly
integrate the GNOME stack with the way things are done on
Solaris (packaging, using Solaris specific API's like auditing
within gdm, the ARC process, etc.).  Since Sun Marketing
believes that the goals of getting an accessible and competitive
desktop is of utmost importance, ARC has taken a bit of a back
seat.  In fact, Sun Marketing has been providing the Sun GNOME
team with a steady stream of waivers which allows Sun to ship
GNOME without having to fulfil the normal ARC requirements.
However, it is doubtful that they Sun marketing can or will
do so indefinately.

In saying this, I should mention that Sun's ARC community has
been very understanding and helpful.  They understand the
tight schedules that Marketing has been placing on our team
and they have been very much working with us to do the best
job possible in the circumstance.  However, ARC has also made
it clear that they expect us to make more headway on stability
issues for future GNOME releases.

In order for a project to be acceptable to ARC, it is necessary
for all public interfaces to be documented and that all changes
to public interfaces be clearly documented from release-to-release
with potential breakages highlighted.  The documentation that the
GNOME community provides via gtk-doc provides us with some of
this needed information, but is lacking in some areas:

+ Current gtk-docs do a good job of documenting library
  function interfaces, data structures, enumerations,
  and macros - but currently do not document how the code
  interacts with the file system or environment variables
  which ARC consideres interfaces of equal importance.

+ Current gtk-docs do not highlight much information about
  change from one release to the next.  The gtk-docs do
  use the "Since" tag to highlight when interfaces were
  added, but the "Deprecated" tag doesn't include information
  about which version an interface was made obsolete.  Also,
  changes/additions/etc to enumerations, data structures, how
  files are accessed, etc. are typically not documented in
  the gtk-docs.

+ ARC considers data files that users or sysadmins might be
  expected to edit or integrate with to be interfaces.  Examples
  would include the gconf database, gtkrc files, theme files,
  etc.  Many of these interfaces are not publicly documented,
  and have no stability guarantees from the GNOME community.
  For example, ARC would like to see that the GNOME gconf key
  namespace be documented publically with some indication
  about what keys are stable, and which keys are supported
  from release-to-release.

+ The GNOME community does not seem to publicly highlight
  what parts of the GNOME stack are considered stable.  There
  does not seem to be an official breakdown of the interfaces
  that clearly states "these interfaces are guaranteed to work
  until GNOME 3.0, these interfaces might change before then,
  these interfaces should be avoided if you want stability
  from release-to-release, etc.

+ It seems that the GNOME community's definition of ABI
  compatibile means something like "you can recompile your
  code with the new libraries and it will work".  Sun's idea
  of ABI compatible means something more like "you can take
  a GNOME 2.0 application package/rpm and install it on a
  system with GNOME 2.6 and it will work.  In other words, if
  the application depends on GConf keys provided by the desktop
  they will still be supported, if the application installs
  mime-files/themes/icons/etc. that are intended to integrate
  the application into the desktop the integration will still
  work reasonably, etc.

What we have been doing to date has been to take the public
gtk-docs and add the missing pieces to create internal documents
for ARC review.  As you can imagine, it is very time consuming.
To start somewhere, we are starting at the bottom of the stack
and going through a proper ARC review process for the lowest
level libraries (glib, pango, gtk) with the hope that over time
we will expand this list so that more of the stack goes through
complete ARC review.  Obviously, few GNOME programs only depend
on glib, pango, and gtk so we need to make quite a bit of ground
before Sun will feel comfortable supporting the average GNOME
program, or suggesting that Sun customers consider using the
GNOME development stack to write their own applications.

In bringing these issues up with the GNOME community, my
hope is that the community will also agree that issues of
stability are generally important to all GNOME users and
might be interested in working with Sun to provide better
public documentation that would also better meet ARC
requirements.  This would make it easier to get more of
the GNOME stack through the ARC process and would mean than
GNOME could be better supported by Sun.  It would also mean
that Sun's ARC community would be reviewing more complete and
accurate documentation and would be better able to send
useful comments back to the GNOME community.

Since the sort of information that ARC requires is typically
of general interest to developers, I suspect that working
towards improving GNOME's developer documentation would also
be of use to the general GNOME community.  If people looking at
developer.gnome.org could see from the documentation that
GNOME takes interface stability very seriously, this could
easily encourage more people to consider GNOME as the right
desktop to integrate with.

I also think that the GNOME community would benefit from more
discussion about how it uses its interfaces.  As an experiment
to see if ARC-related issues are of use to the community, I
have brought up the topic of how GNOME makes use of file
system interfaces in the /var, /etc, /usr/share, and $HOME
directories.  I think that GNOME could benefit from thinking
about such interfaces and how to best organize things to
ensure ongoing stability from release-to-release.

If the community is agreeable, I would like to continue
sharing information about Sun's internal ARC process when it
relates to the GNOME project.  My hope is that this will
translate into better ARC documentation for Sun, and also
provide the community with documentation that is of general
interest - such documentation might encourage the GNOME
community to pay closer attention to its interfaces and
hopefully discuss how to better organize them and make use
of them.

One thing that needs to be fleshed out a bit is how to create
documentation that is useful to the GNOME community and also
meets the requirements of Sun's ARC process.  Since Sun
employees are already obligated to put together such documentation
for Sun's GNOME ARC process, it would be most useful if we could
also put together documentation that would be useful to the
GNOME community at the same time.  But it might take some time
to figure out how to best do this.


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.
Great! Obviously that's good not only for Sun but for everyone in the Linux/BSD world building on GNOME as well. 

Right.  This is why I think it would be better if Sun's ARC process
could better engage with the GNOME community.  Sun's ARC process was
originally created to work with projects that were developed internally
by Sun.  Therefore, the ARC process tends to work well when used
with projects that Sun controls.  To date, it hasn't worked well when
applied to projects that are controlled externally, like GNOME.  I have
been working closely with the ARC-chairs to try and improve Sun's ARC
process so it works better with external projects.


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.
It used to be the case that X was very stable, but that was primarily because as a project it was stagnant. Since the fork and move to Xorg, development has picked up and some breaking changes have been made. For instance I think old X libs have been dropped (libXaw?) and the new ARGB visuals are known to break some apps. You may wish to keep an eye on that.
For Mozilla I guess you're not counting the XPCOM APIs Mozilla exposes which historically haven't been stable at all (see the Adobe SVG Viewer fiasco). In Gecko itself compliance with W3C specs is good, or at least always has been for me. Serious rendering regressions happen but seem rare. 

Right.  I'm not trying to say that any project is perfect.  Your example
of Java breaking ABI between releases highlights another area where Sun
itself could do a better job in this area.  Sun's ARC process is not
perfect, and it doesn't always catch breakages that happen.  However,
Sun's ARC process forces developers at Sun to spend some time thinking
about how things might break from release-to-release and to have some
plan for addressing possible breakage.  Not all breakages are caught by
ARC review, but many problems are prevented.


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.
Let's hope so. Right now it's more of a collaboration forum than a formal standards body. Specs can and do change, sometimes old versions actually disappear from the website entirely, for instance the old vFolder text file spec. 

Agreed.


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.


OK, that seems to make sense.
> /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?
No I don't disagree, I just didn't realise that upgrading without changing file formats was classed as an external interface.
What happens if the config system changes but migration code is in place so that the old config is moved to the new config on first run. Is that classed as a breaking change or not for such interfaces? 

ARC is typically satisfied as long as changes are identified, documented,
and steps are in place to ensure that the user does not notice that things
have changed.  Including situations where a user might install an old
GNOME 2.0 application in a GNOME 2.x environment.  For example, imagine a
GNOME 2.0 program which installs some mime database information onto the
file system expecting it to be picked up by other desktop programs.  But
in GNOME 2.x the mime database has moved and changed format.  Installing
the old GNOME 2.0 interfaces should still work or a straightforward (and
preferably automatic) mechanism should migrate the data to the new format.


User applications should be able to integrate their gconf data to these
file locations and expect them to work from release to release.
OK, I don't know enough about gconf to comment here. I thought it was internal but I can see the schema files in there, so I guess not.
It is the directory on Solaris where we let users know that they can install gtk-doc's that they wish to generate. 

OK. It'd be nice to have that formalised somewhere.


Yes.  My hope is that the PSARC document that I am sharing with the
GNOME community might inspire the community to better formalize its
filesystem interfaces.
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.
Yes, I was referring to the GTK+ developers. Is the gtkrc file considered as stable as the library API itself? I don't know. It almost certainly is but I never saw an explicit guarantee .. 

Yes, we are in murky/undefined ground here.  As I mentioned earlier, the
GNOME community does not clearly define some of its interfaces - especially
file system installation locations, data file formats that users/sysadmins
are expected to change or integrate with, environment variable interaction,
etc.  Sun is assuming this is a supported external interface, but it wouldn't
surprise me if that is wrong.  That is why I shared the PSARC case that
highlights Sun's perspective of the interfaces with the GNOME community.
My hope is to get feedback about what exactly the community thinks is
stable and what is private to GNOME.

Typically Sun likes to see data files only get edited by GUI's.  This
way the data file can be labelled private and only the GUI interface is
the supported public way to change the file.  This way the underlying
data can change, but the mechanism for changing the data can be stable.

Murray Cumming said:

>>> 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.
>>
>>
>> That's a shame but understandable.
>
> No, it's a vague statement, which is even contradicted later when he says
> that SUN do in fact recommend GTK+ and libglade. It's important to be
> precise. Maybe we are talking about libraries that are not part of GNOME
> or not part of the GNOME Developer Platform.

Actually Sun supports the entire GNOME stack, and if a customer makes
use of GNOME interfaces Sun is obligated to support them.  However, Sun
discourages users from using interfaces outside of glib, pango and gtk+
since they do not have sufficient public documentation to go through
a full ARC review.  I hope I have made this more clear.

Mike Hearn said:
>> Glynn Foster wrote:
>> Sun will always strongly support and encourage the use of Java as *the*
>> development platform, period. If that wasn't obvious, I don't know what
>> is.
> I guess I'm confused then - if this is the case, why do Sun care about
> GNOME/GTK+ interface stability? If Java is the one true supported
> platform, why bother working with the community to increase stability
> instead of just saying "these libraries are there to support the
> desktop environment, use them if you like but you're on your own"?
>
> Are Sun interested in GTK+ as a developer platform or not?

Although Sun does recommend that customers use Java as their development
platform, Sun does support customers who use any public interfaces that
are shipped with Solaris.  Since GNOME's interfaces are documented
publically (like at www.gtk.org for example), it is likely that some
Sun customers will use these interfaces.  Sun is interested in improving
the interface stability in GNOME because Sun believes that this will
proactively prevent potential breakages that might cause Sun problems
in the future.

Murray Cumming says:

> But that has nothing to do with how ABI-stable GTK+ is. GTK+ is either
> ABI-stable enough or it's not. If it's not, then let's hear the details.

From a library function perspective, many GNOME libraries have done a
good job of insuring ABI stability.  However, it isn't clear to Sun what
exactly the GNOME community means by ABI stability.  Do they mean that
it is necessary to recompile your code for it to run with a new version
of GNOME, or that a 2.0 application will run with 2.x without needing
recompilation, repackaging, or moving files around to place them in new
integration locations.  Also the GNOME community does not produce enough
information about changes from release-to-release to satisfy ARC.

However, it seems that the community does not focus on interface stability
outside of library ABI compatibility.  Issues like how GNOME interacts with
the filesystem, environment variables, file formats of files that users are
expected to modify or integrate with, etc. between releases seems
generally undocumented by the community.

>> However, that being said, we do have the following libraries with a
>> higher interface level - GTK+, Pango, Atk, Glib and libglade. We do that
>> because we are more confident that the interfaces will more carefully
>> managed to maintain API and ABI compatibility moving forward. Everything
>> else on the stack is almost treated as 'pot luck' by comparison,
>> although there is nothing stopper a 3rd party from developing with these
>> libraries.
>
> I can imagine that SUN has a problem with parts of the GNOME ABI which are
> not declared stable, and/or the extra stuff such as file formats and
> executable names.

Yes, this is more the issue.

> But I fear that we are talking about simple binary ABI-stability of the
> GNOME Platform libraries. If SUN has found that they are not ABI-stable
> then they should be telling us, because we want them to be ABI-stable, and
> we think they are.

Don't fear.  This is not the biggest issue that Sun is worried about.
I'd say that the format of data files that users are expected to change
or integrate with is an area that Sun is much more worried about along
with other interface changes that the community doesn't seem to be
documenting.

Murray Cumming says:

> I know, and that's why I referred to that. But I am interested in
> clarifying the statement that GTK+ is not ABI stable enough. Firstly,
> those examples have not been about GTK+. And secondly, it's important when
> making such statements to be clear about what you mean.

Actually ARC has been very pleased with the library stability found
within GNOME, especially in low level libraries such as glib, pango, and
GTK+.  Sun is more worried about the stability of interfaces higher in
the stack, like bonobo, libgnome*, gconf, etc.

In summary, I'd like to highlight that my goal is to figure out how to
do work with the community to better document interfaces and interface
change.  I have to do this work already, but so far all of this
documentation has been done manually and in an internal fashion that is
of little to no use to the GNOME community.  My goal is to figure out
if it might be possible instead to work with the community to improve
the community documentation so that I need to do less work documenting
such things internally.  This would make the ARC process more effective
at Sun, and would also improve the general developer documentation for
the community.

Most teams the size of the Sun GNOME team have an ARC member as a part
of the team.  Having such an ARC member on the team usually makes things
a lot easier.  Unfortunately, the Sun GNOME team lacks such a person.
ARC has made it clear to the project team that they expect us to do the
work to engage with the community to make these sorts of things happen.
Since I am not really an ARC expert, I feel like I've been thrown a bit
into the deep end of the pool.  I very much appreciate the fact that
GNOME community developers have been engaging in this discussion.  I
hope that we are able to figure out ways to better improve the
relationship between Sun and the GNOME community.  I would like to see
Sun better able to contribute to the GNOME community and I think that
better integration between the Sun ARC and the GNOME communities
would be one way that Sun could better contribute to the project.

--

Brian
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]