Re: 2.3 Proposed Features

[Luis Villa <louie ximian com>]

On Tue, 2003-02-04 at 01:32, Havoc Pennington wrote:
> 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.

If something this damn important is still considered a prototype we
can't be shipping it in a stable release. Hack on it, test it, etc.,
etc., in the unstable releases, but either it isn't a prototype and
/everything/ uses it for the release or nothing uses it at all. We just
can't have a solution where 1/2 our apps are using something and the
other half aren't. That's completely untenable from a usability
perspective and it speaks poorly of our development process that we
can't get uniformity on something that basic. I'm already bracing for
the round of 'but when I opened a file in app X it didn't show up in my
recent files list.' That's going to be a fun/embarassing/whatever thing,
since exactly /two/ applications use it and we're pimping it all over.
It would be sooo much worse in the 2.4 release notes to run around
saying 'oh, look, we've got this nifty new file selector, but only 3 of
your apps are actually going to use it.'

Luis