I am sorry if it is not correct mailing list however I didn't found better for describing problems with testing "Gnome 2.90" due to release process. I tried for some time keep parallel gtk+ 2.x and 3.x install testing new packages with gtk+ 3.0. However it became increasingly hard: - Sometimes packages started to be depend upon non-released version of packages. Sometimes even unwritten. - gtk+ 2.90.6 removed a lot of API/ABI and introduced new one. I understand that it is one of GNOME goals[1] - however it created wide gap between migrated and not yet migrated packages. Additionally some packages required gtk+ 2.90.6 even when it was not needed[2] or require it without marking it in configure.ac (again understandable).[3] - at least one crash bug was commented as of low priority as the crash was in GdkGC on gtk+ 2.0 build [2.31.x] as "[package] master is on GTK+ 3, so this is very likely to be obsolete."[4] which at that point I had installed because of connection of other package which in gtk+ 3.0 version depended on unwritten version of package (now - on unreleased version) While I understand the problems concerning move from 2.x to 3.x I fill that the usage of 3.0 is increasingly harder. However the alpha/beta users are IMHO needed - I can have very different environment then developer and I may use it in different way. For example I may use multi-byte UTF-8 characters and encounter problems in code where number of chars and number of bytes is treated as equal (real live example). I don't want to direct this at anyone - I feel that everyone is acting in rational way trying to create the best software he or she can. However I have feeling that the testing with those releases are harder than usual and creates the above situations. KDE 4.0-like situation would certainly be far from ideal. Regards [1] http://live.gnome.org/GnomeGoals/GDKtoCairo [2] As developer stated he tests it on GTK+ live, which is understandable. [3] On the other hand I understand that "does not build" is fixed earlier then "uses deprecated symbols" [4] To be honest - stack trace was damaged for some reasons (I have debug symbols for all libraries and programs on system) which did contribute to closing bug. However closing was before I replied that stack trace was damaged despite presence of debugging symbols (which can be seen as pointers on stack trace are too low to be from memory-mapped ELF file IMHO)
Attachment:
signature.asc
Description: This is a digitally signed message part