On regressions and carelessness

[Tristan Van Berkom <tvb gnome org>]

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 <jstpierre 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 <tristanvb 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 <otte 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