Re: API freezing ...

[Havoc Pennington <hp redhat com>]

Michael Meeks <michael ximian com> writes: 
>         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 certainly is - what else do you propose? This is how this problem
is normally solved in projects I've been involved in, commercial and
otherwise.

>         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.

There is no sudden knee-jerk here, there is enforcement of a deadline
that's already 2 weeks old in its most-recently-delayed incarnation.

API additions (and even changes) are still allowed, they just need to
be approved by the release team in advance. They will approve truly
essential patches, e.g. accessibility stuff since working
accessibility is a release requirement.

I don't think there's any need to panic, just go to the extra effort
to post changes for the release team to approve, and review what stuff
in CVS will break when a change is made. We are certainly at a
point in the release cycle where everyone needs to be warned about
changes, anyway - we need to be working on the desktop, not libs.
i.e. there is a need to post warnings about changes anyway.
   
>         Wonderful; and I do see this as a pre-condition for hard freezing
> anything sitting on top of Gtk+ / glib.

It really isn't, the expected changes are _extremely_ limited in scope
and should not require changes to API of any other libs.

> 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.

Life sucks, we'll fix it in 2.2. We have already punted numerous GTK
changes that we know full well will have to be worked around or
reinvented later.

>         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.

On the other hand, Nautilus worked with the 1.x platform. We're at
least that good in 2.0. So Nautilus will work fine.

FWIW most of eel-gtk-extensions.c was either converted to trivial
wrappers of GTK, or IMO not really worth putting in a library.  So
sharing is already much 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.

I propose that if GTK changes in the next week actually change what
the API above GTK should be, then the release team can make an
exception. Thus addressing your concern without opening a full-on
loophole.
 
>         This of course being a painful change that will require a
> re-release of nearly everything that uses Gtk+ :-)

But that will not require API changes to any of those things.

> also - it seems
> somewhat strange not to re-use these ( relatively large ) marshallers, or
> is the 'random' the key here ?

See gtk-devel-list archives, take it up on that list.

> eg. Jacob should
> sort out his libglade issues and get them committed if neccessary.

Jacob's change is necessary, so I would expect it to be
approved. However, it's good that it was posted to the list, so we all
got fair warning, and confirmed that it was needed.

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