Re: Rotting patches [was: Re: Reviewed-By: and pastebins]
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. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Rotting patches [was: Re: Reviewed-By: and pastebins]
On Thu, 2012-05-03 at 12:00 -0400, Colin Walters wrote: One of my goals for 2012 is to increase the number of patches I'm reviewing myself, and more generally, even further increase the percentage of patches that go into GNOME that have peer review. 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.) https://bugzilla.gnome.org/browse.cgi?product=FOO provides a link at the right to the list of unreviewed patches for the project FOO. Two examples: * gtk+: 637 unreviewed patches; 480 of them older than 12 months * gnome-shell: 125 unreviewed; 61 of them older than 6 months I wonder if anybody has ideas how (and time) to clean up, e.g. by setting needs-rework or simply rejecting unwanted fixes. Or agreeing in a team to have maximum XX unreviewed patches by 3.6.0 or so. https://mail.gnome.org/archives/patchsquad-list/ was one idea but never took off and has been dead as hell for years. andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rotting patches [was: Re: Reviewed-By: and pastebins]
On Thu, 2012-05-03 at 19:14 +0200, Andre Klapper wrote: While peer reviews are great, **in some projects** teams miss manpower already to have reviews at all, without any peer. If one doesn't have any peers for a particular project, yes, clearly there's no one to review. However we should be able to do significantly better than we are at building out the peering relationships between individual components. (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.) https://bugzilla.gnome.org/browse.cgi?product=FOO provides a link at the right to the list of unreviewed patches for the project FOO. Two examples: * gtk+: 637 unreviewed patches; 480 of them older than 12 months * gnome-shell: 125 unreviewed; 61 of them older than 6 months That does seem very high, but note some of these *have* been reviewed, and both the reporter and reviewer agree there's a needs-work state. I wonder if anybody has ideas how (and time) to clean up, e.g. by setting needs-rework Right; offhand my guess is that's the effective state for at least 30-40% of these. Or agreeing in a team to have maximum XX unreviewed patches by 3.6.0 or so. It's going to be a continual process I think; setting hard targets might help. Just talking about it will help too as we are now =) FWIW, I marked some gnome-shell needs-work/rejected patches as such so something happened besides words... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rotting patches [was: Re: Reviewed-By: and pastebins]
On Thu, May 3, 2012 at 1:14 PM, Andre Klapper ak...@gmx.net wrote: On Thu, 2012-05-03 at 12:00 -0400, Colin Walters wrote: One of my goals for 2012 is to increase the number of patches I'm reviewing myself, and more generally, even further increase the percentage of patches that go into GNOME that have peer review. 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.) https://bugzilla.gnome.org/browse.cgi?product=FOO provides a link at the right to the list of unreviewed patches for the project FOO. Two examples: * gtk+: 637 unreviewed patches; 480 of them older than 12 months * gnome-shell: 125 unreviewed; 61 of them older than 6 months I try to comb through this list for gnome-shell often, looking for ACN/ACAF patches I can push, or and looking through the none ones to see if I can review them. Yes, a large majority of them are still unreviewed, usually because I don't know the state of the patch, nor if we want the feature in the first place. I wonder if anybody has ideas how (and time) to clean up, e.g. by setting needs-rework or simply rejecting unwanted fixes. Or agreeing in a team to have maximum XX unreviewed patches by 3.6.0 or so. https://mail.gnome.org/archives/patchsquad-list/ was one idea but never took off and has been dead as hell for years. andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
