Re: GNOME Enhancement Procedure

[Owen Taylor <otaylor redhat com>]

Joe Shaw <joe ximian com> writes:

> > More as they come to me. :)
> 
> 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)

Since the process is essentially independent of GNOME, except
for the specification of the board as the adjucator of last resort
for some issues, I see no problem using it for loosely
affiliated or even unaffiliated projects.

Most likely in case of failure of the process, Tim and I would try to
mediate (pistols at 30 paces if we can't agree) rather than turn to
the board, but mostly the procedure is based on who is interested in
an issue, not on some fixed set of GNOME people.

I certainly think a RFP process would have helped with both
GObject and ATK in terms of clarifying the rational and
requirements, and making sure the overall designs fit them.

(If a loosely affiliated project _doesn't_ use the process,
well, then we are no worse off than we were before with respect
to that project.)
 
> 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?

This is basically addressed in the implementation section

   Maintainers have final say over their modules, and can thus block a
   given solution proposal from being implemented. However, this is
   considered highly antisocial. Forking or deprecating a module in
   order to implement an important solution that most of the GNOME
   Project agrees upon would be a reasonable step to take. (Although
   doing this has to be carefully weighed against losing the work
   being done by the module maintainer.)

   [...]

   Barring genuine conflicts of interest, this problem should never
   arise; maintainers should be involved throughout the proposal
   process, e.g. they will almost certainly be on the list of
   responsible maintainers making a decision on the RFP and solution
   proposals. As noted earlier, RFPs may be invalidated by the board
   if the RFP owner blatantly neglects to include the relevant
   maintainers in the process.

As long as the maintainers of a project are involved in the process
I think the possibility of errant proposals being approved
is minimal.

And if Tim and I are completely ignoring what everybody in GNOME
wants, then probably you probably should create the Gnome
Toolkit or switch to FLTK ;-)

Regards,
                                        Owen

[ Just my opinion - haven't discussed this with Tim, so perhaps
  the pistols will be needed sooner rather than later ... ;-) ]

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers