[Gluster-Maintainers] Merging patches

[Jeff Darcy]

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.