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
Reviewed-By: and pastebins
Hi, 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. git-bz and splinter make this flow fairly good, however for trivial patches, especially when multiple developers are online at the same time, it can be highly convenient to use a pastebin, then on IRC another developer says ok. In this scenario, I don't want to lose the critical information that the patch has been reviewed (and who reviewed it). So here's the proposal: When doing the pastebin+IRC approach, the person committing the patch, if they have given it a non-superficial review, should add the tag: Reviewed-By: Jane Doe jane...@example.com to the git commit. This should mean exactly the same as it does in the Linux kernel's use: http://kerneltrap.org/mailarchive/linux-kernel/2007/10/8/332384 If patches have gone through bugzilla (as many nontrivial patches should), then it's not necessary to add the tag in the git commit as well, as long as the link to bugzilla is maintained, the information is stored there. Opinions? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reviewed-By: and pastebins
On Thu, May 3, 2012 at 12:00 PM, Colin Walters walt...@verbum.org wrote: Opinions? It would be nice if git-bz and splinter could work together to get Reviewed-By tags added automatically. In general, more patch review is of course a good thing, and keeping a better record of it is a great idea - as long as we can keep it from devolving into a bureaucracy. But I'm not sure if we can set a gnome-wide policy on this - we're hosting a ton of projects with fairly varied maintainership styles... it is probably most productive to establish this as a best practice for the core modules, and go from there. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reviewed-By: and pastebins
Hi, On Thu, May 3, 2012 at 12:00 PM, Colin Walters walt...@verbum.org wrote: In this scenario, I don't want to lose the critical information that the patch has been reviewed (and who reviewed it). So here's the proposal: I think when the person who reviewed a patch is critical information, then the details of the review is normally also important. I don't think the person who reviewed a patch is always critical information, though. Certainly, drive-by pastebin patches should be trivial and obvious. If the proposed changes aren't trivial and obvious, then they should go to bugzilla first so there is a paper trail leading back to the discussion. Basically, adding the reviewer's name doesn't hurt anything, but my opinion is it doesn't necessarily help either. What does help is knowing that the patch was sanity checked at all (like you said), and not committed blindly, and at that point adding the person who did the sanity checking doesn't seem like a bad idea. --Ray ___ 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
