Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)

[Luis Villa <luis villa gmail com>]

On 6/10/05, Owen Taylor <otaylor redhat com> wrote:
> On Fri, 2005-06-10 at 10:21 -0400, Luis Villa wrote:
> 
> > But the last time we rushed out a gtk-gnome paired release, and got
> > ourselves locked into the new APIs so that we couldn't back out, the
> > result was that any distro actually paying attention would have
> > noticed that our 'latest stable set' was *not actually stable* by our
> > normal standards. *That* undermined the release process (or should
> > have, if people paid attention, which it turns out they don't.) If we
> > don't ship 2.8, it should be because our collective experience and our
> > testing data is telling the distros this is not yet ready for prime
> > time. By not shipping 2.8, we're not asking them to figure out what
> > the latest stable set is- we're telling them what the latest stable
> > set is, and telling them that gtk 2.8 is not part of that, because it
> > is not likely to be stable, given our experience. If distros want to
> > overrule that, that's fine, but honestly, aes, elijah, bkor, kmaraas
> > and I know a fuck of a lot more about the stability of GNOME than any
> > of the distros do*, so if they want to overrule that, that is their
> > own problem.
> 
> It's *not up to the GNOME release team* to say
> when a GTK+ release is stable. That's up to the GTK+ team. I think
> our general take on that is that the day we release 2.8.0 we
> are committed to ABI and API stability, 

As an aside, when I say 'stable', I mean 'reliable for users', not
'API stable for developers', and maybe that is part of the confusion
of this thread. I expect GNOME .0s to be both stable (in your sense)
and reliable (in mine.) GTK 2.4.0 was stable in your sense, but not
reliable in mine, and that is why release team is wary of telling
people that a gnome .0 based on gtk 2.8.0 would be reliable.

> but our general expectation
> from past experience is that we do find and fix significant numbers of
> bugs in the first few maintenance releases after that.
> 
> But the GNOME release team has *no* ability to say "don't ship GTK
> +-2.8.x until we release GNOME-2.14."

I'm not claiming we do or should. You get to release .0 whenever you
want, and users get to use it whenever they want. Release-team gets to
say when they think it is reliable, and hence worthy of being part of
GNOME. Ideally your .0 and our .0 should have the same qualities, but
in our past experience they have not.

This whole conversation is unfortunately sounding very hostile, which
was not my intent. Let me try to back it down a little bit and get it
back to the first principles, explain why (IMHO) gtk 2.4.0 was not
reliable enough for GNOME 2.6.0, and see if/where/when we can
compromise from those.

With GTK 2.4.0 and GNOME 2.6.0, 2.4.0 was not stable, and apps all
over the desktop crashed, which made GNOME 2.6.0 look bad. This didn't
happen with GNOME 2.10, mainly IMHO because 2.6.0 was released a full
three months before GNOME 2.10 was, allowing for extensive testing and
several GTK point releases. Avoiding a repeat of this very difficult
problem is my primary concern.

GNOME generally avoids this with three big strategies:

* avoid entanglements and only release things that are ready: we look
at apps case by case and if necessary reject them if they aren't ready
on our timeline[1]. This only works if the apps do not provide API to
other parts of GNOME, or if their API has not changed. Unfortunately,
this can't be the case for GTK- we must be entangled for good testing
to happen, so we can't just get to september and say 'gtk isn't ready,
punt it.' This means that if we choose to go with gtk 2.8.x, 2.8.x
*must* be rock-solid stable at the GNOME 2.12.0 date, we have to punt
apps that have upgraded their deps to 2.8.x, or we have to slip. (Or
we can ship a .0 we're not happy with, but I'd like to think that
isn't an option.)

* aggressive freeze schedules: we freeze early, and ask for early
releases. As has been pointed out, this does reduce features in favor
of stability.

* extensive testing: while we've been doing a poorer job of this than
we used to, we still rely heavily on extensive testing of unstable
releases to make our .0 releases as stable as possible. Because people
are nervous about testing gtk, we know it gets less testing than other
parts of the stack, even though it needs it more.

So, options as I see them:

* don't depend on gtk 2.8. This is suboptimal for all of us, in that
gtk gets less testing, is less stable, etc., but goes a long way
towards guaranteeing a reliable platform for GNOME 2.12 development
and deployment, which is important for everyone.

* tentatively depend on 2.8, and if 2.8 is not reliable when we need
to ship 2.12, punt all apps that have chosen to depend on 2.8 and
can't remove those dependencies in time. This is pretty suboptimal, in
that developers will be forced to make a choice- depend on 2.8 and
risk being tossed from the release, or go the safe route, but not get
the new features, and not contribute to testing.

* do a hard depend on 2.8, and accept release slippage if our testing
shows 2.8 isn't quite reliable enough. This is obviously the best-case
scenario for gtk (maximum testing, no rushing if it isn't ready),
close to best case for app developers (predictability about API), but
pretty suboptimal for the history of reliabilty we've been trying to
maintain, and for any partners who have been counting on that
reliability.

* do a hard depend on 2.8 and don't accept release slippage. That
means we are actively choosing to downgrade the importance of GNOME's
.0 quality in favor of getting new API out there and release
timeliness. I would personally hate to see us choose that route, but
there are not-insane reasons to choose it.

Of course, these options tend to assume that 2.8 won't be reliable
and/or timely. Constructively, we can do some things to make sure 2.8
actually is ready, and not coincidentally reduce the nervousness of
the groups who got burned last time:

* release early, release often: Mattias has indicated willingness to
basically punt all 2.8 features and focus on stability/polish, which
is great, but as of this very moment there isn't even yet a 2.7.0 that
people can play with, even though we asked for the first 2.11 tarballs
six weeks ago and your own schedule calls for them last week. Those
delays make the release team nervous. A visible commitment to being
feature frozen and releasing early and regularly would go a long way
towards reducing release-team worries, both for this release and in
the future.

* testing: aggressively push FC4, SUSE 9.3, and Ubuntu Breezy users to
install and abuse gtk 2.7. Each of the major distributors could
(should?) package 2.7.0 and send mails to their appropriate user-lists
saying 'GNOME needs your help, try these, here is the apt/yum/rug repo
where you can get regularly updated gtk packages.' Obviously that
won't stress the new APIs, but any old APIs with new codepaths will be
tested, and if the distros also released some 2.11 applications that
use the new APIs via the same release/distribution mechanisms, that
would go a long way towards increasing QA team confidence. [This does
not necessarily need to be done by the distros, but there is no one
else doing build work ATM :/

So... that's my summary. I hope it helps get us focused on the
important stuff (what should GNOME's strategy be release-wise) and off
the defensive 'who gets to decide what' stuff that I certainly helped
foster.

Luis

[1] we have probably not been aggressive enough in this, to be honest,
though we're trying to get better- hence the after-the-fact oaths
about gtk and gnome schedules.