Re: About GNOME 2.0 - The end of a dream

[Seth Nickell <snickell stanford edu>]

> Suddenly, I'm now the bad guy and I get flamed from almost everybody,
> so it's time for me to face the truth and see that my work on GNOME 2
> is no longer appreciated.

I have been astounded time and again by the amount of single-handed work
you have been doing to make GNOME2 a reality. I have been meaning to
start helping with this myself (feeling very guilty that you have been
working so alone), but underwent a very stressful finals week and now
need to find a job. Your work is *extremely* appreciated, at least by
myself.

With regards to the dream of a componentized GNOME...though its not my
foremost dream for the future of GNOME, it seems like a very good goal,
and I laud the efforts that have gone into making this a reality for
GNOME2. This particular conflict is, in my eyes, more about the
replacement of something that many members of the community (myself
included) viewed as a "done deal" with a new system. 

This has bothered me both by the lack of due-process and even more so
because it "concerns" one of the dreams I have for GNOME...that of a
networked GNOME where the user doesn't have to care where they are they
just have their settings. I saw GConf as a very important piece of that.
This dream is at least as important (I'll be honest, more important) to
me than a fully componentized GNOME, and I suspect that may be true of
some others who have objected.

Can I propose the following compromise:

1) "gconf:" is re-written to be a wrapper for GConf
2) "config:" aliases to "gconf:" and is STRESSED as the default that all
programmers should use unless they have a damn good reason not to.
3) libgnome be written using bonobo-config (since this is already done),
but we use "gconf:" as quickly as possible to test it and get all bugs
worked out of the system (hopefully the number of bugs will be reduced
by using the fairly well tested gconf, though obviously the wrapper is
going to need to provide *some* extra functionality here).
4) Havoc devotes himself to fixing any stability issues or bugs that
result from using gconf (I think he already is, and gconf seems well
tested and stable at this point, but we can make this explicit since
people have voiced concern about gconf in this regard)

As Havoc has repeatedly pointed out (and I have yet to here a clear
rebuttal of) this should satisfy the technical desire to have a clean
set of CORBA apis to access the configuration system, but will allow for
use of the "C-only" GConf interface as well. This also means existing
programs like Nautilus will not have to worry about migration, and a
well tested backend will be used. (plus all the GConf advantages like
being able to select a new backend). Martin, Michael, etc will be able
to continue to write libgnome code using the bonobo-config APIs which
they prefer (and has the additional benefit that it is closer to being
able to bridge with the old config system using the "gnome-config:"
moniker).

I hope this preserves at least a large extent of everyone's wishes, hopes, 
dreams and aspirations. 

-Seth