Re: Suggestions for API/ABI Process

[Mark McLoughlin <markmc redhat com>]

Hi Brian,
	I haven't had a chance to read everything because its all very verbose
and stuff, but it does look broadly to be pretty good.

	Some comments though:

 - A lot of this reads like "you guys don't care about stability". In 
   reality what you're proposing is to add more process, documentation 
   and clarity around what we're already doing.

   i.e. the community understands the need for interface stability, 
   especially API/ABI stability, and has actually done a damn good job 
   here since GNOME 2.0. Recall that the ABI audit Sun recently did on 
   GConf, glib, pango, atk and gtk+ showed that the only "real" ABI 
   change was Sun's own doing ...

   You point out the libgnomeprint ABI breakage. Be aware that most in 
   the community was unhappy about that, but even then (AFAIK) the 
   maintainer did his best to make sure vendors could upgrade without 
   breaking existing apps - he made it possible to parallel install
   that version with the previous version, probably by following this
   advice:

     http://ometer.com/parallel.html

   The point is, that the community already cares about interface 
   stability a lot more than you suggest in what you've written. This 
   is a question of formalizing and improving what's already there. 
   Expect people to get very defensive if they think this is "you guy 
   suck, we'll show you how to do this properly"

 - We don't do things like "a declaration of stability from the module 
   maintainer". The way things might happen is that the stability level 
   of stuff will be written down, discussed and changed until there is
   broad consensus that it reflects reality.

 - You have a column "Supported by Red Hat". I don't think that has any 
   relevance and I'm not even sure what that actually means or where 
   the information came from. I think its bogus, basically.

 - You're suggesting writing a lot of documentation. I'd suggest you 
   figure out what documentation is really very important to this 
   process and minimise it as much you can. Certainly don't make full 
   API documentation a requirement for anything. People do want full
   API documentation, but its a question of people having time.

   i.e. don't demand work from people. Unless you're willing to do it 
   yourself, of course :-)

 - Figure out what you really need people to read and summarise it 
   concisely somewhere. If you need a verbose version too which people 
   can consult for detailed guidance, fair enough, but your first goal 
   should be to get as many people as possible to have a good rough 
   understanding.

Cheers,
Mark.