Re: Rotting patches [was: Re: Reviewed-By: and pastebins]

[Benjamin Otte <otte gnome org>]

Andre Klapper <ak-47 <at> gmx.net> writes:

> Offtopic, but the obvious first step would be to improve the rate of
> reviewed patches in general.
> 
> While peer reviews are great, **in some projects** teams miss manpower
> already to have reviews at all, without any peer.
> (And if you are a first-time contributor and you never receive feedback
> on your first patch you give up and won't know where to escalate. That's
> where GNOME's contributor base remains small.)
> 
I think Bugzilla is a terrible tool if you lack manpower, in particular if the
manpower for a project is shrinking relative to the amount of bugs. I don't
think Bugzilla was ever designed for the "you take over a project, here's 1000
bugs as a head start, it'll increase by 50 every week" case.
Bugzilla works very well as long as you keep it in check, but once it grows too
much and the necessary triage doesn't happen, you lose without a real chance to
ever get it under control again. It's a bit like a zombie outbreak in that 
regard.

Another thing is that Bugzilla is essentially a large TO-DO list. Those lists
require a certain kind of mindset that is a given for every developer. I think a
large part can work well with it, but there are some that just can't [2]. I am
one of those people.[4]
Because I don't keep a TODO list though, I'm not usually in the need to get
anything done.[2] So you can just poke me on IRC and I there's a high chance
I'll review patches if I know things about the code you're looking at. I might
even fix a bug that you have, just because I know how.

> * gtk+: 637 unreviewed patches; 480 of them older than 12 months
>
I'm these days the main developer of GTK with Matthias together. GTK has > 2500
open bugs[1]. So it has passed the zombie outbreak state by now.
So I don't look at bugzilla at all. I want to get things done. This means 2 
things:
(1) If you file a bug for something I broke, I'm not gonna know - unless
Matthias (who's the only one triaging those 2500 bugs sometimes) throws it at me.
(2) I'm not gonna care about bugzilla statistics, target milestones, bug
severity or anything else people do in there.

I have no idea how to improve that situation. The only possible solution I can
even come up with is getting more developers to work on GTK - first learning the
internals of the toolkit and then working on the bugs.
But I have no idea where those people would come from.
 
Benjamin


1: https://bugzilla.gnome.org/page.cgi?id=weekly-bug-summary.html
2:
http://slobotski.wordpress.com/the-pmarca-guide-to-personal-productivity/
3: http://www.paulgraham.com/makersschedule.html

4: A very sincere Thank You for that goes to both Red Hat and GNOME for
adjusting themselves to work with me this way. It's not easy to work with
someone who's so different than you are.[see also 3] This totally should not be
a postscript, but it'd really confuse what I wanted to say above. Again, thanks.