On Fri, 2005-06-10 at 13:10 -0400, Luis Villa wrote: > 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. I'd argue that we may well be straying to far on the "reliable" side for GNOME. I'm not convinced we can do interesting development, stabilize down completely, and release on a 6 month time schedule. If we want to get real world testing before the code freeze, then we have to have something that a lot of people are using within 4 months after the release cycle opens. Acknowledging that the initial release may have a few rough edges gives us some "pipelining", where the final stabilization of the last cycle gets parallelized with the start of development of the next release set. I'm not arguing for any radical changes here, just the realization that the only way you get zero-boogs is by having zero-development. If we don't do that, then I think we need to think about switching to having phased releases of some sort (like the old RHL 6.0, 6.1, 6.2, 7.0 model) > 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. I think this is slightly exaggerating the situation ... there were definitely issues with the file selector, but the file selector wasn't used *that* extensively in 2.6.0. And on the other side, the file selector had been under development for quite a while, but there is only so far you can go in an unused version of GTK+ ... it took about a year of real world banging on the file chooser for it to get to a state that's pretty satisfactory now. 2.8.0/2.10.0 were almost certainly a better release because the file selector appeared in GNOME-2.6.0. Let me reiterate that the version of GTK+ that goes into GNOME-2.12 is up to the release team. At this point, GNOME-2.12 isn't going to be depending on Cairo in interesting ways, so there wouldn't be huge disruption from making GTK+-2.6.x the official GNOME-2.12 version. But I really do want to get Cairo out there and in use as soon as possible and we'll be putting Cairo/Pango-1.9/GTK+-2.7 into the devel branch of Fedora within the next week or two. Note also that maintenance on GTK+-2.6 will more or less be dropped when we release GTK+-2.8.0 or soon after: the GTK+ team just doesn't have the resources to maintain multiple stable branches. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part