Re: GNOME Enhancement Procedure

[Havoc Pennington <hp redhat com>]

Joe Shaw <joe ximian com> writes:
> 
> The only thing that concerns me about the whole process is how things
> that do not fall completely within the GNOME project will work with it.
> GConf and GTK+ are examples that I can think of offhand.
> 
> Using GTK+ as an example, if the GObject or ATK stuff were being done
> after this were in place, would they have to submit to this process as
> well as the normal GTK+ process? (Which is usually a proposal to the
> list, some discussion, and approval from Havoc, Owen and/or Tim)
> 
> If they wanted to put GnomeCanvas (or some other large scale widget, or
> gdk-pixbuf, or whatever) in GTK, do they have to follow the process?
> What if it gets turned down, despite arguing that it might be of benefit
> to more people? I doubt we would end up forking GTK, but how would we
> enforce this?
> 

Right, it's a tough issue. Especially for GTK. 

For something like GConf I think it's pretty easy. Say we decide via
this process to do something I'm not willing to do for GConf, and the
GNOME Project thinks it's a pretty big deal.

What I would say is that then GConf should be phased out of the GNOME
Project, replaced by some other solution. As the GConf maintainer I'm
free to continue with GConf, it just won't be the solution to the
GNOME requirements, GNOME will have some other solution. Maybe the
GNOME solution will be based on the GConf codebase, maybe not.

Presumably if I decided to go this route as maintainer, it would be
because I had some other target audience for GConf I was still
interested in supporting, unless I'd just lost interest entirely.

Anyhow, basically I won't be able to complain if GNOME uses something
other than GConf, or a fork of GConf maintained by someone else,
because I was unwilling to meet the GNOME Project needs, and GNOME was
sufficiently interested in those needs to have someone else do config
system work. i.e. what's been established is that I'm not willing to
move GConf in the same direction as the GNOME Project, there's a
conflict of interest there, GNOME has a better solution, and we should
amicably part ways.

(This is all hypothetical of course.)

So, the reason GTK is harder is that realistically forking the 500K
lines of code comprising GTK and dependencies would be damn near
impossible (especially without Owen and Tim's level of knowledge of
that code).  Furthermore porting GNOME away from GTK would be damn
near impossible.  GConf is much easier to replace, being only 11K
lines of code or so and more or less not rocket science.

Anyhow, basically I think it would be appropriate for GTK and
dependencies to use this procedure. But I have to agree with you I
don't know how we can enforce it. On the other hand, I would hope that
Owen and Tim would participate in good faith.

(Random thought: I'm not even sure a refusal to comply with the
procedure by Owen or Tim would necessarily be wrong in all cases - GTK
_does_ have users outside the GNOME Project, even some on Windows. If
the RFP process resulted in a decision that made sense for GNOME but
not for GTK considering all users, what then?)

My optimistic view is that the RFP process would involve Owen and Tim,
and would arrive at a win-win sort of compromise that took this kind
of thing into account.

I would hope that the process is intended to make people talk to each
other until they agree, rather than to push a solution on a
strongly-opposed maintainer. In the end it all comes down to common
sense, rationality, etc., the process is just a way to a) actually
make a decision that's communicated b) give people confidence their
voice was heard and that they didn't miss important stuff c) slow down
and be sure people talk to each other...

Havoc