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

On 6/10/05, Mark McLoughlin <markmc redhat com> wrote:
> On Thu, 2005-06-09 at 19:00 -0400, Owen Taylor wrote:
> > - To be realistic, if GNOME-2.12 is released after GTK+-2.8,
> >   most distributors are going to ship using them together.
> >
> >   So, the release team could decide to go with 2.6 even with
> >   the current GTK+ schedule, but the result then would be less
> >   testing of what people actually ship.
>         Yeah, and that would significantly undermine the whole release process
> IMHO. If the value of having GNOME releases is to have the very latest
> GNOME technologies released as a stable, coherent and integrated set,
> then by creating a situation where distributors go off for themselves
> and figure out what *really* is the latest stable set of GNOME
> technologies, we really reduce the relevance of GNOME releases.

I'm all in favor of getting 2.7 tested and released, and I think we
should push hard to test it with 2.11. That'll obviously help it get
better, and fast.

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.


*except JDS

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]