On Wed, Sep 20, 2006, Frans Pop wrote: > The main question I guess is: is there more information on if/when 2.10 > could migrate to unstable? What is the chance that it will make Etch?
The biggest instability in Gtk 2.10 is due to the new filesystem module asynchronous implementation. In short, this feature permits opening the "File open..." dialog (the "picker") empty, and filling it's content in a separate thread while continuously responding to user input. In other word, the UI doesn't hang when opening a large directory. This particular issue was a bit rushed to make it in 2.10, and it was afterwards considered to revert its inclusion. See the upstream thread for details: <http://mail.gnome.org/archives/gtk-devel-list/2006-August/thread.html#00068> It seems upstream is currently trying to address all known issues related to this change instead of reverting the code, so I suppose Gtk 2.10.4 will show whether they have succeeded in stabilizing this feature. Another problem of switching to Gtk 2.10 is the transition it involves due to the backward incompatibility with modules. This affects 19 source packages, three of these are under the control of the GNOME team. The transition needs some source changes, but these are relatively simple. IMO, the advantages release-wise of the new Gtk counter-balance this transition, but this didn't get any release team acceptance yet. One important part of the decision will be on the side of debian-boot@ as well. It is not innocently that I wishes you test the Gtk 2.10 udebs. If you do happen to find showstoppers for your uses of Gtk with the new release, it might kill the idea of 2.10 in etch. On the contrary, if you happen to find big advantages of 2.10 over 2.8, it would be an argument in favor of pushing 2.10 into etch. > Main reason I ask is that there are a few RC issues in the graphical > installer (not crashes, but important presentation issues) that should be > solved in 2.10, but are still present in 2.8. > If the chance that 2.10 will _not_ make Etch is high, then we need to try > to find fixes for these issues in 2.8. If that chance is negligible, we > can concentrate on testing with the 2.10 libs. I don't think the chances are negligible, so I'm willing to work on any outstanding issues that you see with 2.8 to build a solid backup plan. (Please continue focusing on 2.10 as the primary target though.) Here's what is already ready for a gtk+2.0 2.8.20-2 upload: * New patch, 009_revert-gdkdrawable-directfb, to revert a fix for Italic letters which caused ugly unneeded horizontal/vertical lines; thanks Davide Viti. (Closes: #386860) * Fix typo, install-dfb depends on build-dfb, not build-shared. Other things that need to be done: - addition of the pixmap engine - fix the empty /etc/gtk-2.0/gdk-pixbuf.loaders (#382435) Could you list any other thing that you consider RC or important that still need fixing in 2.8? > No, cdebconf in unstable is built against libgtk-directfb-2.0-dev > So we do need to make this change. Oh, my mistake, I was looking at the sources both in etch and sid at the same time, and didn't notice cdebconf/sid was using the new lib. Then the changes I have described are recommended indeed (but the current package will continue building exactly as well as it did until now). -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
