Re: About GNOME 2.0 - The end of a dream



Havoc Pennington wrote:

> Hi,
>
> So Miguel, it's fine to say let's all be happy lovey, but what
> happens when there's genuine disagreement and it isn't possible for
> everyone to get what they want?
>
> What happened in this case is that Dietmar with your blessing went and
> reimplemented my functionality so he wouldn't have to talk to me,
> because you "got tired of arguing." But then it turned out that this
> just delayed the conflict - we still had to have the same argument
> now, AFTER he did all the work, because only one config database can
> be the central config database.
>
> So I'm trying to learn from this situation. How should I have handled
> it? How could we have reached agreement BEFORE doing all the
> bonobo-config work and having this flamewar? I feel that I presented
> very rational reasons why bonobo-config would work as a wrapper at the
> time, and why that was better and met everyone's requirements, and
> then you stopped discussing the topic. I don't know what I could have
> done. I don't think I was flaming during that original discussion.

This is simple to answer: You always argued that everything is an
implementation detail: Monikers, bonobo, CORBA_any, ... But that are the
things we wanted to get fixed. You rejected to include that work into
GConf. If I remember correctly that was even before the 1.0 release, at a
time where not many Applications have used GConf. I am sure we would have
a really nice GConf implementation if I put all that work into GConf
instead of bonobo-conf, but you rejected to work together because you
don't like the bonobo dependency and because you cant see any advantage
of our approach.

And you still argue that way. For example: You say that using CORBA_any
is now possible, and that you may use it sometimes to cleanup the code.
But you also say it's worthless to cleanup anything, because that is only
an implementation detail.

Another argument was that you want to stay compatible, and that would
mean to keep that ugly GConfValue forever. One can change such things
relatively easily in early design stages (when we talked about that, cant
remember the date), but it gets more difficult if more programs use the
code. What you called an "implementation detail" is know a compatibility
requirement, ....
The same is true for your "internal" CORBA interface -> You now say that
is a compatibility requirement. The situation gets worse if we have more
configuration backends. Suddenly GConfBackendVTable will be a immutable
interface because we need to be compatible.

Summary: We simply got the deep impression that you are not interested in
changing anything, and that is why we started bonobo-config.

Anyway, a rewrite is sometimes the best cleanup ;-)

- Dietmar









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