On 6/10/05, Owen Taylor <[EMAIL PROTECTED]> 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. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list