Re: 2.3 Proposed Features

[Havoc Pennington <hp redhat com>]

On Tue, Feb 04, 2003 at 12:08:53AM -0500, Ettore Perazzoli wrote:
> On Mon, 2003-02-03 at 00:50, Havoc Pennington wrote:
> > I don't think blocking on GTK 2.4 is a good idea really. If GTK 2.4
> > happens to come out in time, we can include GTK 2.4 in the release,
> > but GTK 2.4 won't be locked down soon enough to make GNOME 2.4 depend
> > on it. Would send our release schedule down the tubes.
> 
> Why are we assuming that it's more likely for GNOME to be out on time
> than for GTK?  Is there a specific reason why the GTK release cycle has
> to be longer?

I guess I just don't buy that GTK 2.4 with its current feature plan
will be releasable in time to still get GNOME out on a good
schedule. If we dropped the menu/toolbar stuff and the combo stuff
maybe. Those two are big, hard, and controversial.  If we do only the
filesel plus small stuff I am willing to believe we could do GTK 2.4
early enough that GNOME 2.4 could use it.

Big new APIs are slow to finish, and really hard to punt when they
aren't done in time, because people have started using them, and the
toolkit itself uses them, they're in the docs, and in the test apps.
We can't punt menu/toolbar after many GNOME apps are already using it,
suddenly GTK 2.4 would become feature based because the features are
dependencies.

I would feel more comfortable relying on GTK if Owen had a minion or
two. Right now the only "generalists" that regularly do arbitrary GTK
work are Owen and Matthias Clasen. If Owen has to take a week to fix
gdm bugs for Red Hat Linux, then the GTK schedule is pushed out a
week. There's no one else to pick it up. With the large number of
people working on GNOME, individual distractions tend to average out a
bit more.

> If we were talking of less important features, I could agree with having
> separate release cycles, but in the case of the file selector we are
> talking about a pretty basic one.  I don't think GNOME 2.4 should go out
> with a new file selector and no API to use it.

We've gone round and round for years on how to prototype/test APIs
without locking them down. By definition a prototype is:

 - a temporary API that will eventually move somewhere permanent
 - subject to frequent change
 - not something we want to lock down or support
 
Yes this means apps using the prototype get extra work porting to the
final API, but what are you going to do about it. It seems inherent in
the concept of trying something out that you may decide you don't like
it. And that's what a prototype is.

The mistake is putting prototypes somewhere we can't get rid of them,
like libgnomeui.

Havoc