API freezing ...

[Michael Meeks <michael ximian com>]

Hi Guys,

        It is my belief that people are overstepping themselves here;   
while we all want to get Gnome 2.0 out _quickly_ - it is also my belief
that bringing in a cumbersome procecess ( of facism ) is not a sensible
way to achieve this whatsoever.

        It is clear that we need to harden our freeze - but at the same
time, allow changes that have little or no upstream impact to be made
without a long delay. I think that (limited) API additions are fairly     
reasonable, occasional breaking of bin-compat fair enough, and that as
long as we can maintain this we are heading in the right direction
currently - and there is no need for sudden knee jerk, un-discussed
reactions.

On 13 Nov 2001, Owen Taylor wrote:
> Well, "essentially" is the important word here.

        It is an important word for several other modules;  particularly  
where module authors have indicated that there is still API settling going
on in an area. It seems reasonable to me for eg. Gtk+ to be completely
frozen - except in a few well defined areas.  Accessibility is only one   
area where things have to work before we can freeze them.

> There are a small known set of API changes that are still open. Almost
> all of them should have minimal impact on downstream parts of GNOME.
> Tim and I are working hard to get these done this week; when we do
> that we'll release 1.3.11 and declare it API frozen.
  
        Wonderful; and I do see this as a pre-condition for hard freezing
anything sitting on top of Gtk+ / glib. Furthermore, I see a lack of real
API use as a more compelling reason not to hard freeze something - that we
will later have to totaly re-invent, or laboriously work around.

        It's only now as we start to port Nautilus, that we realize
various things can be shared, made more optimal, moved, massaged etc. to
make everything better.

> We'll make sure we mail gnome-2-0-list about any changes we make this
> week that might have a downstream impact. (*)

        I propose that we forestall any hard API freezing action until at
least Gtk+ and below is hard frozen.

>  - Not installing random marshallers from gtkmarshal.h. If you
>    are using marshallers you need to generate them with
>    glib-genmarshal, and we should enforce that.

        This of course being a painful change that will require a
re-release of nearly everything that uses Gtk+ :-) also - it seems
somewhat strange not to re-use these ( relatively large ) marshallers, or
is the 'random' the key here ?

        So; can we go back to normal and let reasonable small additions to
the API continue unencumbered by uneducated criticism ? eg. Jacob should
sort out his libglade issues and get them committed if neccessary.

        Regards,
        
                Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot