There's nothing like starting the day with a good rant. As I'm sure many of you know, I'm the project's most active committer. I'm certainly not the most active *reviewer*. There are several other candidates for that; my money's on Niels. I'm even further from being the most active *author*. In fact my output in that area is a bit pathetic and I'm the first to admit it. But here's a way to see who's actually pushing the "submit" button.
git log -n 1000 --format=format:%cn master | sort | uniq -c | sort -nrk1 When I run that, I consistently find myself at the top. Sometimes I have more commits than the next two - usually some combination of Pranith, Atin, and Raghavendra G. I mention this not because I'm proud of it but because as a member of this project I'm *ashamed* of it. Things shouldn't be this way, but they are because... *** Long review queues destroy development velocity *** As more patches sit in the queue, the potential for conflicts increases *exponentially*. Those conflicts require code to be rebased and (slowly) re-tested. Often, they re-open debate on the patch contents. That can be healthy, but just as often it means differences of opinion or aesthetics delay patches still further. (I'll rant about good vs. bad code reviews some other time.) The rebase/retest treadmill slows everybody down, and that's not just theory. I've seen it every time I've gone on vacation or deliberately taken a break from active merging. Other projects have seen it too. It slows us all down, it adds frustration to all of our lives, and it feeds into a perception of Gluster as a stagnant project with apathetic developers. I *loathe* the fact that I have to take several breaks a day from my real job - which increasingly involves projects beyond Gluster - to keep that queue moving. My numbers are inflated because many of the patches I merge are trivial. *Anybody else* could have merged them, but days go by and nobody does. Other times I merge patches which have met all requirements, in areas that supposedly have active maintainers, but again days go by and they still sit there accumulating conflicts. So kudos to those three I've mentioned, and to Niels, and to others who are doing their part to keep the project moving. To the rest of you, and especially to the other project-level maintainers who are supposed to help "fill the gaps" but are notably low on that list, please step it up a bit. Don't be afraid to hit that button. Mistakes will be made, "in flight collisions" will still occur and have to be resolved, but those issues are relatively easy to deal with. The *chronic* problems associated with a long and slow review queue are far worse. Let's try and make it so people don't feel like they have to go start a separate project to get any kind of development velocity. _______________________________________________ maintainers mailing list [email protected] http://lists.gluster.org/mailman/listinfo/maintainers
