Gnome 2.32, Gnome 3.0 & gtk 2.90.6 from alpha (pre-alpha?) user point of view

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

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 (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

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.


[2] As developer stated he tests it on GTK+ live, which is
[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

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