Re: Outsanding GLib/GTK+ API bugs

[Owen Taylor <otaylor redhat com>]

Bill Haneman <Bill Haneman sun com> writes:

> >Here's what I said when the issue first came up in April:
> >
> >   At this point, I don't believe that adding multiple-display support
> >   is a feasible goal for GTK+-2.0.0. As you can see, the list of
> >   API issues that we still have to deal with at this point, at what
> >   we've been targetting hard as our API freeze date, is quite long.
> >
> >   I'd certainly like to discuss your proposal with you at at GUADEC to
> >   make sure that we can get it in as soon as possible after
> >   GTK+-2.0.0. And if there are any minor changes that need to be made
> >   now to make this posssible, we probably can slip them into GTK+-2.0.0.
> >
> >   Unfortunately, I simply have not, up to now, had the time to go over
> >   your interfaces in detail :-(, so without regard to issue of 
> >   debugging, trying it out in practice, making sure it makes some
> >   sense for all ports, I just don't think we have enough time to
> >   do the final refinements to get something we sure that is right
> >   long term.
> >
> >   As always, you have to draw a line somewhere so you can move on
> >   to the next release. Rest assured, there are many, many things
> >   that I wish I could do for this release, but are not feasiable
> >   for GTK+-2. at this point.
> >
> >This is the same message I tried to convey at GUADEC, and since
> >then. It seems that I didn't succeed in this. 
> 
> Hi Owen:
> 
> This is indeed what you said before GUADEC.  However it is *not* what Erwann and I 
> came away from GUADEC.  Our (mutual, we thought) understanding at the end of our 
> GUADEC meetings was that you were much more comfortable with the proposals, having 
> seen them, and Erwann worked to expedite making all the changes you requested 
> immediately upon arrival.  

Hmmm, what I remember coming away from the discussions there was:
 
 - Confidence that the necessary changes could be done in a binary compatible fashion
 - A rough consensus that we would  do a follow-on release in a short timescale 
   after 2.0.

But that's water under the bridge... 

> For our part, we tried to clarify the point that 
> multi-head was more than a must-have for 2.0, from an enterprise perspective - it 
> was essential if Gnome is to be put forward as the 'standard' enterprise desktop.

While I appreciate the fact that multihead support is an essential
feature in some application areas, other features in GTK+-2.0:

 - Workable text and tree widgets
 - Complex-text and RLT support
 - Accessibility support
 - Etc. 

Are _also_ essential features. We can't do everything at once if we expect
to be able to release and to release something that we feel comfortable with.

And there are certainly other very important issues that couldn't be
done for 2.0. For the average user of GTK+, even, I suspect, on
Solaris, the current state of the GtkFileSelection widget is going to
be a bigger issue than the lack of multihead support. We have to
do what we can for 2.0, then move on and do more for 2.2.

> >I'm very aware that it's now 5 months past GUADEC and we still
> >aren't completely frozen. But this is _not_ a reason why we can
> >say "well, one month more or less won't hurt, let's just slip
> >feature X in.".
> 
> We know that you, like us, have a lot on your plate.  But the re-emergence of the 
> suggestion to punt multi-head has come as a shock to us, as Erwann has been 
> awaiting feedback from the GTK+ team for quite awhile now without mention of it.

While the same comment as the one that you noticed in the last status
report was in my June 30'th status report, I have certainly not done
as good a job as I should have indicating what the real case was here.

Partly, this was because until I had a chance to review the changes in
detail there was still a remote possibility in my mind that they might
just be close enough to go in. (The review indicated to me that this
was definitely not the case.) But mostly, it probably was just me not
paying enough attention.
 
> I still think we should identify what the real risks and issues are and see what 
> can still be done to address them. 

The issues I would identify are:

 * The API changes have gotten no review outside Sun other than myself.

 * I spent over a week of work going over the changes to do an initial
   review; I would fully expect merging into head to take at least this
   much work from me again to do a final merge into head once Erwann
   has finished implementing. This is time I don't have.

 * Even ignoring the availability of resources from experienced GTK+
   hackers,any reasonable schedule for getting this work merged would 
   involve making changes deep into the period when we need to be freezing
   and doing bug fix work.

 * There are still major issues that haven't been fully discussed (a big
   one being if it is possible to close an open display connection.) 

> At this point, since the proposal is to finalize the few external
> API changes required now, and add the multi-head support compatibly,
> the API freeze doesn't seem to be the issue here.  If the changes
> truly are compatible, they can be backed out at any time prior to
> Gnome-2.0 Beta should they prove unstable.

Just because API changes can be made in a backwards compatible fashion, doesn't
mean that they can be made for free. Once we put in the multihead
APIs, we'll be committed to maintaining them for a minimum of 2-3 years.

And backing out a large change is in no way free:

 - Conflicting changes may have been made.
 - You are suddenly debugging and testing a different codebase.
 - People may have started using the new APIs.

If there is anything I've learned working on GTK+, it is that API changes
need to be done with a lot of caution. If you get something wrong the
first time, fixing it later is not easy.

Regards,
                                        Owen