Re: GConf debate ... the hermenutical key

[Havoc Pennington <hp redhat com>]

Jody Goldberg <jgoldberg home com> writes:
> 
> Gnumeric still uses the gnome_config cruft specificly because of the
> ambiguity in direction between pure gconf and bonobo-conf(ig).  I'd
> rather not waste the time migrating to an api (gconf) that may be
> deprecated in favour of PropertyBags.

But in this case we can support both APIs for quite some time without
trouble, by using bonobo-config as wrapper.

> Delaying the jump to new interfaces is what has slowed gnome
> development and forced revolutionary rather than evolutionary
> api change.

I disagree. I think revolutionary change is more or less necessary to
have stable APIs. 

Evolutionary change in APIs is Eeeevil. 
 
By "revolutionary" I mean clean breaks that install in parallel. 

By "evolutionary" I mean constantly adding new entry points and so on
in the stable branch, or fragmenting the platform by versioning
specific modules incompatibly, e.g. "the gnome libs linked to xml1" or
"the gnome libs linked to xml2" as two incompatible worlds. Because
libs have interdependencies the number of possible platforms grows
rapidly with the number of libs, unless you lock specific lib versions
and keep them there.

The worst case is what we had with GTK 1.1.x, where you had to pick
random subsets of apps. i.e. some required GTK 1.1.13, some 1.1.14,
some 1.1.15, etc. - so they all conflicted with each other.

> - libxml : We should have made the jump to 2.0 as a group long ago
>   (eg post 1.2) Look at the bugs and wasted effort due to continued
>   use of the old code.

There's no way we could have made that jump without causing major
hosage, because it would increment the whole platform, not just
libxml. That's the catch.

> - gtk : I'm sure it has lots of wonderful improvements but after two
>   plus years there are so many that it will be a huge mouthful to
>   swallow and port to.  For 2.0 applications seem likely to be
>   minimally ported to the new api, just enough to get them working.
>   We'll need a number of point releases for the apps to get caught
>   up to the platform and start actually using the new features.
> 
> If we're going to use a new api we need to get it out there more
> quickly and not build up swaths of semi overlapping 'pending' apis.
> 

I would have been all for a more granular GTK release cycle,
unfortunately Pango and GObject both took 1.5+ years to develop, so a
smaller upgrade release was pretty much not possible.

Havoc