Re: 2.3 Proposed Features

[Christian Meyer <chrisime uni de>]

Hello Havoc,

first of all, thanks for your reply :-)

On Mon, 3 Feb 2003 00:50:08 -0500
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.

Ok, that's fine. But as I explained in a previous mail, a 6 months
release-cycle is too short. We don't have enough developers to do that and IMO
it's safer to have a 8 or 9 months release-cycle where we can fix more critical
bugs.
I'll try to fix some bugs in nautilus when university is over; right now I
don't have much time. I think there're several other people which have the same
problem.
Also, I don't want to mess my studies, it's too important. I'm already spending
too much time with GNOME. Look what's happened to Martin Baulig :(

> We should however have a plan for using cut-and-pasted bits of GTK,
> some stuff to consider:
> 
>  - this way GNOME 2.4 can be using the new file selector UI, for
>    example

We really should finally have a new file selector and I hope it'll be doable to
cutnpaste the code from libegg. Although, I'm not feeling good when thinking
about pulling some code from another lib.

>  - if the cut-and-pasted bits are named in the gtk_ namespace, when 
>    real GTK 2.4 comes out there will be symbol collision issues
>    we need to avoid. Thus cut-and-paste bits should probably be 
>    in egg_. But policy here is required.

And here's the problem. Where do you want to put in the libegg code? In
libgnomeui? I don't have a good idea how to solve it. As I mentioned, having
GNOME to depend on libegg is usually not a good idea :(

>  - we need to get these 2.4 APIs tested prior to locking them down 
>    (another reason to release GTK 2.4 *after* GNOME 2.4, so we 
>    are sure we have all the kinks worked out of the APIs and have the 
>    UI design we want for the GTk widgets)

And for GNOME2.4.1 you want to make it depend upon gtk2.4? *yikes*
Why should there be so many problems with gtk2.4. Maybe I just don't know about
the real problems, but gtk2.2 wasn't that problematically.

>  - on the other hand, we're going to want the stuff landing in gtk+
>    module in CVS as soon as it's relatively in shape. Which is kind of
>    in conflict with having the stuff living where it's testable
>    by apps that can't rely on GTK+ unstable branch.

That's when we'll have a 6 months release-cycle ;-)
The software can't be extensively tested, but it's very important to do that.
 
>  - perhaps instead of cut-and-paste we should install static-only
>    libraries? Or even dynamic libs with -DWNCK_I_KNOW_THIS_IS_UNSTABLE
>    type pedanticism.

static libs? OMG! Please no. :(

> A *possible* approach here is to kick GNOME 2.4 out as soon as we can,
> say in August, which would mean we start on GNOME 2.6 in August.  If
> we then plan GTK 2.4 for October, there are a couple months where
> GNOME CVS HEAD could depend on GTK 2.4 and work out the final GTK
> issues.

February -> August == 6 months. Fine. Gnome2.2 is out now, or will be on
wednesday. How can you convince developers to hack on Gnome2.2 and Gnome2.4 on
the same time? It'll take some time until developers will focus on Gnome2.4.
Let's say, Gnome2.4 hacking starts in late March/early April, then there'll be
4 months to hack on Gnome2.4. This is quite an unrealistic target; it just
isn't doable. I'm really trying to be optimistic, but that timeframe freezes
me.

> At least kind of - on the other hand, the classic release plan keeps
> the main focus of development (tinderbox, release team attention) on
> the stable branch for a month or two after it comes out, so GNOME 2.6
> doesn't really start in earnest until October, just as GNOME 2.4
> doesn't really start in earnest until March or early April.

Well, I think you've noticed the problem.
 
> So that would imply that getting GTK+ 2.4 APIs well-abused would mean
> kicking GTK+ out to more like December. So we might want to be looking
> at the libegg approach as our primary testing venue.

If gtk2.4 will be out in DEC, then there'll be the need to pull some code out
of libegg, but IMHO this isn't a nice solution at all.

Greetings,
Christian