Re: Putting the 'Mono debate' back on the rails

["Eugenia Loli-Queru" <eloli hotmail com>]

On 7/22/06, Matthias Clasen wrote:
> If those guarantees are more important to you than playing
> by the rules of the Gnome Bindings set, than Gtk# may
> simply be better of staying outside...

First, we have to see the problem from a high level and ask ourselves: is 
Mike's goal to not break compatibility with existing Gtk# apps incompatible 
with the rules of the Gnome Bindings release? In my opinion, it is not. You 
can easily say the following: you are going to follow the Gnome Binding 
rules, you are going to break the GTK# code to 3 sub-levels or as required 
by Gnome (e.g. bindings for gtk, gnome-core and gnome-desktop, with new 
library names), but for the next 12 months you are going to provide a fourth 
set of libraries and headers that are fully compatible with the old GTK# 
monolithic way. With these 12 months you are offering a migration path to 
your existing third party developers, as this fourth "legacy" build will be 
building by default (and should be configurable to not be built if a distro 
doesn't want it). Yes, this will add a bit of workload initially and a bit 
of Makefile magic, but at the end, I think it's important to abide to the 
Gnome rules for modularity, and at the same time to cater for your existing 
devs.

Now, speaking as the maintainer of www.GnomeFiles.org I tend to watch 
developers and their activity like an owl. I usually notice who is active 
and who is not. The point of the matter is, GTK# has only about ~50 
truly-active apps today. From these 50, the 10 of them are very well done 
and important for a generic Linux desktop (e.g. Banshee, F-spot, 
Monodevelop... Bless & SportsTracker are some other favorites of mine).

If you are not going to provide the suggested fourth "legacy" build in 
parallel to the new gnome-oriented modularized builds, and you indeed decide 
to break compatbility, I suspect that 15 of these active GTK# will update 
their makefiles to compile with the new set of libs/headers within a month 
from your gnome-oriented release. I expect another 10-15 to do so in the 
next 3 to 6 months. At the end, you might "lose" 20 applications, tops --  
which is not the end of the world. And by becoming part of the Gnome 
ecosystem and consequently get installed by default on more distros, will 
bring you 20 new apps fast-enough anyway. In conclusion, I don't believe 
Mike's rules and Gnome's rules are incompatible. But if Mike decides that 
they are, he will still not lose much of the current GTK# momentum 
application-wise.

Instead, what I am personally concerned is API/ABI stability *after* GTK# 
becomes part of Gnome Bindings. Currently, builds of new versions of Mono 
are breaking binaries compiled only 3 months ago (TomBoy is just one example 
in my case). This is unacceptable IMHO for a good desktop experience. If 
both Miguel and Mike can guarantee to the Gnome Project that newly compiled 
gnome-gtk# apps are guaranteed to be working in the forseeable future with 
newer versions of Mono and GTK#,  and he abides to the Gnome Bindings rules, 
personally I would be very happy to see GTK# as part of the Gnome Bindings 
release.

Rgds,
Eugenia