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, 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." My point there is not that I expect 2.8.0 to be buggy, but basically that when mclasen is deciding on what version of GTK+ to go into a Red Hat product, or when federico is figuring out the same thing for Novell, there's going to be a lot more information and factors available to them then to the release team several months previously. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part