Re: GNOME Namespace Management - ARC & GNOME

[Brian Cameron <Brian Cameron Sun COM>]

Mike:

> > > 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.
> >
> > That's the promise that we make about the Developer Platform. That's been
> > fairly successful. Where it's not, a fuss should be made, ideally during
> > the development cycle.
>
> It's not, the promise is that the ABI as defined by things like symbol
> naming, structure sizes, on disk formats etc are stable. However, changes
> which break both applications and bindings, including GNOME itself, have
> been made. A fuss was kicked up and ignored.

Well, the GNOME definition is a bit confusing.  It states:

   Do not break ABI. For instance, if an application uses 2.6.0,
   installing 2.6.1 should not intentionally break that already-installed
   application.

So, the current definition does state that you shouldn't break an already
installed application.  This implies supporting interfaces that are not
binary.  However, the "Do not break ABI" part could easily mislead some
people into thinking that only binary interfaces need attention.

> You're right, there's a lot that GNOME gets right about interface
> stability. It's a leading light in the free software community in many
> respects. But there's a middle ground here that people ignore: what
> happens when changes are made that break software but fall outside the
> maintainers definition of ABI stability?
>
> In this case, it's possible to be both ABI stable (by the strict
> definition of ABI) but not semantically stable, or to make changes that
> are technically bugfixes but nonetheless break some significant (number
> of) programs. 
>
> What I've been trying to figure out is how far Suns
> commitment extends: take the example of GObject construct only properties.
> Would ARC have let this change through, if glib was written by
> Sun?

ARC would let such a change go through if the team responsible for GObject
dealt with the change in a manner that supports users of the interface.
ARC would want the team responsible for GObject to ensure that it made
reasonable efforts to identify what programs would be affected and to
work with them to ensure that any user upgrading GObject also upgrades
any affected programs at the same time.

If such a change caused a user program to break, then Sun would have to
figure out how to appropriately patch the system to keep things working
for that user.  Keeping multiple versions of a library on a system, for
example, might be an approach that would be used to support such users.

The point of interface stability in Sun is not to prevent change, but
to ensure change happens in a controlled fashion.

--

Brian