Re: ARC & GNOME [Was: How we make decisions...]

[Ryan McDougall <NQG24419 nifty com>]

On Tue, 2004-30-11 at 12:32 -0600, Brian Cameron wrote:
> Havoc/Others:
> 
> Thanks for the historical perspective of GEP.  That's useful to hear.
> Personally, I would like to avoid having a discussion where we only
> talk about process and theory - so I'll inject some practical ideas
> and suggestions about things we can do to improve the relationship
> between the GNOME community and ARC.  My hope is that I can highlight
> ways that we could more closely work together that would benefit both.

[very insightful stuff snipped]

I'm really psyched to see Sun so interested to become involved with the
community on this -- the beauty of FOSS is that this is beneficial to
all parties involved. But I also know that part of the open development
"way" is that everyone wants their say via email, but the responsibility
of implementing the work is all individual. :)

My suggestion to Sun is then to milk this thread of ideas before it dies
with a whimper (as all foss threads must), is to harvest all the ideas
from this thread, then start a new thread with the proposed patches to
gtk-doc, and proposed processes. My only word of caution is, given that
most people are not paid to work on most of the things they do around
here, any process proposed needs to be simple, clear, and light enough
(unlike GEP was) that it wont defeat itself by causing developers to
refuse to be bothered with it.

Concrete suggestions off the top of my head:

1. Processes

  Create a "GNOME Steering Committee" with a simple mandate: decide the
lifetime of the various public API/ABIs. Should libgnomeprint die? What
parts of libegg should go where? What libraries are "Stable"? What part
of what libraries are public? Thousands of small details that are really
beyond me, and directly affect ISVs like Sun go here.
 - Couple guys (from RH, Sun, community-at-large, etc) meeting once a
year, light and simple
 - Everything open to community discussion
 - Nothing here infringes on the module maintainer's prerogative

 Voluntary Template processes for 
 - proposing modules, proposing major API changes, etc
 - emphasis on explaining the technical context for discussion and
identifying relevant parties
 - obvious and simple are the watchwords

2. Tools
 gtk-doc: While you have Sun engineers roving the source, lets get them
to improve the level of documentation while they're at it -- it can only
improve the situation. I wonder how bugs are caused by people
misunderstanding the API based on incomplete information? Furthermore if
the ABI is undocumented then how can you document it changing?

I'd like to see some concrete ideas form other people following this
thread, so jump in! 

Cheers,
Ryan