Re: GNOME Enhancement Procedure

[Maciej Stachowiak <mjs noisehavoc org>]

On 18Jun2001 07:45PM (-0400), Havoc Pennington wrote:
> 
> Hi,
> 
> Here's a draft of one way to try and avoid this kind of extended
> flamewar. Let me know what you think.
> 
>   http://pobox.com/~hp/policy.html
> 
> Two example topics we might use for a test run of the procedure are
> this -config issue, and the sound server/API issue.
> 

I have three comments. 

First, even though I think we do need some kind of more formal
process, this one sounds a bit too bureaucratic for my tastes what
with all the rules and regulations.

Second, how do you determine whether a proposed change needs to go
through this process? There are certainly gray areas. I have a feeling
there might be a lot of fights over whether a needed change needs to
go through this procedure, and people making changes without following
the procedure.

Third, how do you determine who the "Responsible Maintainers" are? For
example, in the recent bonobo-conf situation, one could argue that (a)
only libgnome and bonobo-conf are relevant, since the question was one
of using bonobo-conf in libgnome; (b) one could argue that gconf is
also affected since this could lead to a move to deprecate it in the
platform; (c) one could argue that bonobo is affected since ; (d) one
could argue that any program that uses at least one of gconf or
bonobo-conf is affected, since, after all, they must live with the
consequences of the decision; or (e) one could argue that programs
that want to use some API for settins are affected since, for example,
gnumeric is blocked from using _any_ good configuration API so long as
the future is unclear.

Which of these makes the most sense? One could argue that maybe only
the people closest to the problem should be deciding, but if the idea
is to make sure that the project's architecture meets overall
requirements, then one should include at least the major consumers of
those architectures in defining those requirements.

And finally, there are a lot of smart technical people involved in
GNOME who don't necessarily maintain any modules, or work a lot in
areas where they are not maintainers. I think it would be better if
any technical review process we had was designed to include them as
well.

My own proposal would be to have one or more standing architecture
review committees to consider issues with global architecture
implications. 

Regards,

Maciej

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