[no subject]

>         Let me quickly outline the policy:
> 
>         "If you want to include compat code, you need to add the string
> 'libgnome1-compat' to your pkg-config dependency list"
> 
> 	Fairly easy to explain, lucid and simple, IMHO.

I fail to see how two policies can be easier to understand than
one policy. And your policy simply does not work for GTK+...
 
[....]
 
> >  - Using #defines allows integration of the docs for the deprecated
> > functions with the main docs using gtk-doc. gtk-doc will catch the
> > #ifdef when parsing the headers and put a warning by deprecated
> > functions.
> 
>         Problem with documentation is that if a method is documented,
> people tend to use it - the converse being true too. The compat code is
> simply to make porting easy; we have no desire for people to be easily
> finding out about and using these old and nasty APIs. If they need to,
> there are always the old API docs to refer to.

What is someone more likely to use accidentally:

 - A function they cut-and-pasted some from some code from
   somewhere and couldn't find any docs on.

 - A function documented with a big Warning next to it:

   http://developer.gnome.org/doc/API/2.0/gtk/gtklabel.html#GTK-LABEL-GET  

> >  - And least importantly, but not irrelevant - adding extra functions
> >    to a library has very little overhead - adding extra libraries
> >    has a big overhead. This is a consequence of the way ELF works -
> >    basically you need to do a hash table lookup for each loaded
> >    library.
> 
>         Well - lets say that this was the determining factor in startup
> speed, and that it was a totaly unneccessary addition, and that the
> library sat on top of plain gtk+. On my system an ldd on gtk-demo has 19
> shared libraries linked in - with more at runtime no doubt; so we'd add a
> 5% performance penalty. Not significant in terms of some of the builtin
> algorithmic inefficiencies around the place.

Well, you are assuming the ability to put all the compat stuff
in one library.

 -lgtk12-compat -glib12-compat -lgnome-compat 

Is already three. Then imagine the next release:

 -lglib12-compat -lgtk20-compat -lpango10-compat -latk10-compat -lgtk20compat
 -lgdkpixbuf20-compat ... -lgnomeui1-compat -lbonobo-compat .....

This is not a scaleable way of going about things. And how
are you going to about deprecating things without breaking
binary compat ... this isn't even possible with your scheme.
 
> > This is one of the points of having consistent FOO_DISABLE_DEPRECATED
> > macros ... it's very easy for automated tools to track what what entry
> > points are deprecated and check if a library is using them.
> 
>         It's extremely easy with a separate library - you just do:
> 
>         ldd my-broken-app | grep 1-compat
> 
> > And since -DFOO_DISABLE_COMPAT allows deprecation on the individual
> > function level, we can make sure that all functions that need to be
> > deprecated are deprecated.
> 
>         This is nice indeed, but not a big issue for Gnome 2.0 I think.

I don't see why we should be using a deprecation methology for
gnome-libs:

 - That doesn't work for most of our libraries
 - That doesn't allow method level deprecation
 - That doesn't work with our doc tools
 - That won't work for future versions of GNOME

When we have a better one available.

Regards,
                                        Owen