Re: GNOME 2.0 planning: A longer range roadmap

[Havoc Pennington <hp redhat com>]

Hi,

I think we've agreed on strict-freeze-by-July as an acceptable plan,
just to mop up loose ends...

Maciej Stachowiak <mjs eazel com> writes:
> Havoc Pennington <hp redhat com> writes:
> 
> > 
> > I agree with you; our job at Red Hat Labs is in large part to deal
> > with providing a platform for people to build on. So we are supposed
> > to have a plan here.
> > 
> > But believe that the Windows GUI toolkit platform is about 20% of the
> > size of GTK+. It has order of 15 widgets, at least that show up in
> > Visual Studio. So let's not get too panicky that we don't have an
> > UltraFrobinator in the platform. 
> > 
> 
> The windows development platform is a lot more than that unless they
> shrank it a lot since the last time I used Visual Studio. I could
> probably name 15 acronyms for different technolgoies that are part of
> the platform: COM, ATL, MFC, IE, DirectMedia, Direct3D, DAO, VBA, DTC,
> ICM, ActiveX, GDI, DDX, ODBC, MTS.
> 
> This is not even counting the upcoming .NET stuff.

I am aware of that, I did say "GUI toolkit." ;-) Our deficiencies
vs. Windows are not in the toolkit area, they are elsewhere. I happen
to believe that the GNOME project is the wrong place to address a lot
of this, but I know people will disagree. Anyway, tangent. Point is,
libgnomeui does not address any of those issues, and I hope it won't
try to. Neither will GTK+.
 
> Merging everything into Gtk is definitely not, IMO, the best way to
> solvce this problem.

I'm not advocating that btw...

> > If your goal is
> > to create a quality devel platform to get these developers, frantic
> > hacking on the libs is NOT the way to get there.
> 
> I don't understand why it's assumed "any gnome-libs changes" ==
> "frantic hacking".

That equation is historically true. I think I am basically arguing
against the way gnome-libs has been done in the past, and wanting us
to come down hard and say "no more."  i.e. I want process in place so
that it will become usable. If we are going to insist that libgnomeui
is intended for professional developers, then we need to maintain it
accordingly. You probably agree.

However, people have "agreed" in the past, with no results. ;-) So I
would like to make sure that there's genuinely no conflict of
interest; that there is genuinely somewhere else for what Alan calls
"gwiz" to go, and that somewhere else doesn't even have a pretense of
being a platform for professional developers. Because I don't want the
pressures to put unfinished things in libgnomeui, and I do want a
space for innovation to happen.
 
> I don't want to set it up to be a competition. It's just that I don't
> like people setting all kinds of policies and requirements for others
> that they are not willing to follow themselves. Your response to this
> above basically seems to be "Gtk is more important so it should be
> special", which I just don't buy (even though I do think Gtk is more
> important, I don't think that means it should get to be special).

That's not my argument.  It's not like "GTK is more important so it's
special," more like "GTK had somewhat different goals than those I'm
advocating for GNOME 2 so exceptions to the policy were made to
achieve those."

Honestly GTK 2 was not strongly release-date-driven and was not trying
hard to hit a fixed release date, thus the exceptions that were
made. Those exceptions to the policy clearly did screw our release
schedule. I am arguing that GNOME 2+ should be different in this
respect, it should be trying to hit that fixed date. Mostly I'm saying
that because everyone on the board felt that way. I'm not sure we
should ignore the goals people want for GNOME 2 because GTK didn't
have the same goals.

gnome-libs is typically in a position to do the same as GTK. Aside
from this specific release, where upgrading to GTK 2 forces our hand
(and if not for i18n/accessibility which are "emergency features" for
industrial use, I'd be willing to say we don't upgrade to GTK 2 until
GNOME 3), normally you could release GNOME the desktop regularly while
making libs feature-driven, in the same way that libxml2 and GTK 2 are
being adopted when ready by the GNOME release we happen to be
on. i.e. the desktop keeps going on the old libs, until the new
versions of the libs are ready.

Even with GTK 2 forcing our hand, gnome-libs _has_ had 2 years and
_does_ have 4 more months until July. So if nothing is happening in
that time, I think it's maybe a lack of maintainer attention to that
library, rather than a too-short schedule.

> I don't think libgnomeui is the only relevant question here. For
> example, I'd like to change a couple of things incompatibly in OAF for
> GNOME 2 because I think there are some serious design flaws in there
> but I didn't want to dealay GNOME 1.4. I am not going to buy into a
> policy of not changing anything.

Sure, we can change some stuff. But let's keep it under control with
the hard July freeze.
 
> July sounds like a great date for API freeze to me. Do you hear that
> everyone? Me and Havoc agree on something! :-) Maybe we can get
> consensus on just this one point and figure out what that means.

Honestly I think we agree on about every big point and this thread is
mostly intended simply to get on the same page about details and
underlying reasons. That's my intent anyway, to communicate exactly
how I'm thinking about this stuff in addition to what I'm thinking.

> > 
> > There are two ways to do that:
> > 
> >  - add the features bin/source compatibly, and add them in the next 
> >    compatible release (as with GNOME 1.2, 1.4)
> 
> Most features we have in mind are source compatible, but this doesn't
> totally finesse the issue in the case that someone starts using a
> half-done feature.

I think the solution there is to be sure your freeze is far enough in
advance that you could yank uses of the feature in addition to the
feature itself, if necessary. (But probably not for features that can
just get moved into libgwiz).

> >  - make a branch, work on the features, release an incompatible
> >    version, add incompatible version to the platform on the 
> >    next platform-breaking release.
> 
> This has indeed worked great for Gtk and libxml, but has not worked as
> well for gnome-libs. 

Why not? I think the reasons for that are enlightening. ;-)
 
> OK, you are convincing me, but this leaves open the question of what
> to do with gnome-libs for GNOME 2.0. I guess there is not time to add
> a whole lot of new features to gnome-libs HEAD, but I think there is
> time to finish up a lot of the things that were started.

Yes. I've backed off my original thought which was "revert to
gnome-libs stable branch." ;-) The July freeze will work, if it
actually happens.
 
> > So my suggestion is, you first have a feature like that in the devel
> > platform release schedule, then in the _separate_ desktop release
> > schedule you have the feature "take advantage of new devel platform."
> 
> That makes sense to me. I guess one problem is that with a heavily
> layered devel platform, it may take many releases for a feature to
> fully percolate up. 

That's right, it's the "accordion effect" I mentioned in my long-ago
Dependencies Suck Manifesto you may recall. This is one of the reasons
that gratuituous interdependencies between modules suck. But I don't
see any magic way around it. Just try to keep things modular. ;-)
 
> I actually think you and I have very similar views on what stuff
> actually should and should not get done, we just have really different
> ways of approaching it that make it sound like we totally disagree.

Yep.
 
> We also have to pick a hatchet-man empowered to butcher such non-done
> features, and an appeals process for exceptions (like, say, vote of
> the foundation board, which basically means impossible because most
> people on the board care more about releasing on schedule than any
> given feature, but it's good to have an out).
> 

Yes indeed. I think the release coordinator should absolutely be able
to get a freeze on the libs in the release. I would like to see all
the core library maintainers agree to the freeze date in advance and
agree to abide by the group decisions on this as a principle, before
there are specific issues at stake.

Havoc