Dear fellow hackers, I am sorry to bore you all with this email, I've tried to resolve this in bugzilla and IRC and failed, if I am to have any trust in GTK+ development practices, I must unfortunately share this conflict in public.
Around a week ago, while I was tirelessly spending my evenings and weekends improving Glade, I noticed a height-for-width regression in GtkBin derived widgets. While this might not be serious or noticeable for many GNOME core applications, the regression sticks out like a sore thumb in Glade (since Glade uses wrapping labels for all of it's property editors, in the interest of economizing space), and frankly I expect GTK+ to be much much more than just a toolbox for the current GNOME core applications. The regression was originally introduced in the 3.8 cycle with this commit: commit f4438a1ffc6aaab92fb6b751cd16e95c2abaa0e3 Author: Jasper St. Pierre <jstpie...@mecheye.net> Date: Thu Nov 8 19:13:52 2012 -0500 Which was signed off by Benjamin Otte. My course of action was to fix the regression, as this is code of my own doing, and I spent many hours getting it right the first time, I understand that I have license to fix these things, but fixing it would not be enough, because if I just fix the regression, who's to say that this type of careless regression will not recur in the future ? So, in the interest of notifying those responsible for the regression, I first opened this bug: https://bugzilla.gnome.org/show_bug.cgi?id=698433 Naturally, I wanted to be sure that those who removed code and caused regressions will pay better attention in the future, so I put Jasper and Benjamin on CC explicitly in the bug report, in the hope that they will learn from this and be more careful in the future. So, I closed the bug after fixing it with this commit: commit b164df74506505ac0f4559744ad9b59b5ea57ebf Author: Tristan Van Berkom <trista...@openismus.com> Date: Sat Apr 20 17:52:16 2013 +0900 And all was well in the world again, labels wrapped and requested enough height inside their check buttons. Until yesterday, when I updated my local copy of GTK+ sources again and rebuilt Glade and found the nasty behaviour again. This was a blow to the face, the regression was silently re-introduced without re-opening bug 698433, without even acknowledging that there is a serious misbehaviour caused by this commit. After looking through the commit log today I find the offending commit commit b8e4adfff9ba62330a71ea7498595227979bb4f0 Author: Benjamin Otte <o...@redhat.com> Date: Mon Apr 22 08:23:08 2013 -0400 This looks very irresponsible to me, and is alarming for several reasons. a.) It seems that the regression is only a matter of Benjamin's taste, he does not like how things are implemented, and instead of changing the implementation, he has simply removed code and caused regressions. b.) It seems that Benjamin's superiority complex transcends the need for software that actually works. He would rather have the last word and break GTK+ in doing so, than swallowing his own pride and living with some code he doesn't like, at least until which time he could replace it with code that works without introducing regressions in the meantime. This is called "too cool for school". c.) Worse still, he presumes to suddenly turn this in to my own problem. It is his prerogative that he remove code that does not suit his taste, and that the regressions he causes should be my own fault. That I should devote more of my own time to change this implementation to his taste, for "free as in beer". All I ask of you, dear fellow GTK+ developers, is that responsibility be taken for your own actions. If your code introduces a regression, you should be responsible for fixing that regression, it's not right to introduce regressions and expect that others clean up the mess you leave behind. Carelessness is something that we all practice at times, but we should strive to be less careless. If you read code and you are uncertain what it does, "Assume people mean well", don't assume that it's useless and can be safely removed. Removing code that you do not understand is almost certain to cause breakage. By all means, simplify code that you do not understand at first sight, by first understanding why it exists and then replacing it with something that is more readable, that is a step forward, careless removal of code however is not a step forward. I hope you will understand the awkwardness of this, it is with much regret that I bring this topic to the list. I sincerely hope that measures will be taken to avoid this type of carelessness and irresponsibility in the future. Best Regards, -Tristan _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list