Re: Last gasp - Mailing list pgsql-hackers

On 04/10/2012 01:28 PM, Robert Haas wrote:
> The fact is that we have no shortage of committers - there are 19
> people who have access to push code into our master git repository.  A
> handful of those people have basically completely left the project and
> their commit rights should probably be revoked on that basis; most of
> them are still involved in one way or another but just not able to
> devote a lot of time to reviewing other people's code.

Let's use realistic numbers here:  I count 7 people who regularly review 
and commit other people's code in a variety of areas.  There are also 
several subject matter experts who commit things in a relatively narrow 
area.  But most bigger patches are going to hit a bottleneck whose 
capacity could be measured in 3 bits.

I would actually be happy to have more of the people whose commits were 
expected to be in targeted areas.  It's not like anyone who commits 
outside of their scope of expertise is going to survive doing that for 
long before getting publicly shamed and/or booted.  The pressure to not 
screw up is so high in this project, I suspect concerns over making a 
mistake is behind some people's reticence to commit other people's work.  Committing sketchy code that blows up later
isstill going to haunt 
 
its committer, regardless of the original author.

> Giving more people the ability to
> commit stuff will neither force them to devote time to it nor make
> them qualified to do it if they aren't already.

There are a couple of directions from which I don't completely agree 
with this.

To use a personal example I don't think is unique, I would set aside 
more time to hack on the documentation if I didn't have to bug one of 
the existing committers each time I wanted to work on something there. 
It really feels like I'm wasting the time of someone who could be doing 
more difficult things every time I submit a doc patch.  I'd merrily 
write more of those and consume things like the never ending stream of 
corrections from Thom Browne if I could turn that into a larger part of 
my job.  I don't do more of that now because it's very unsatisfying work 
unless you can do the whole thing yourself.  Knowing everything is going 
to pass through another person regardless removes some of the incentive 
to polish something until it's perfect for submitters.

As for broader concerns about whether people will alter their quality of 
work based on being able to commit, I'd suggest turning a look at 
yourself.  Your quality of work was high before it was a primary job 
goal, but it's surely gotten better now that it is, right?  Seems that 
way to me at least.  But it's really hard to get funding to work 
full-time on this project unless someone can commit their work.  There 
are plenty of people contributing here who rummage up enough part-time 
hours to develop the occasional feature, but not quite enough to make 
things perfect even by their own standards.  And not being recognized 
for your work on the project can be a self-fulfilling prophecy.

The main reason I worry about this is because of a very real chicken/egg 
problem here that I keep banging into.  Since the commit standards for 
so many other open-source projects are low, there are a non trivial 
number of business people who assume "!committer == 
![trusted|competent]".  That makes having such a limited number of 
people who can commit both a PR issue ("this project must not be very 
important if there are only 19 committers") and one limiting sponsorship 
("I'm not going to pay someone to work on this feature who's been 
working on it for years but isn't even a committer").

There are a significant number of companies who are willing to sponsor 
committers to open-source projects; there are almost none who will 
sponsor reviewers or "contributors" of any stature unless they're 
already deep into the PostgreSQL community.  That's one of the many 
reasons it's easier for a committer to attract funding for core 
PostgreSQL work, be it in the form of a full-time job or 
project-oriented funding.  The corresponding flip side to that is that 
the small number of committers is limiting the scope of funding the 
project can accumulate.

I'm somewhat oddly pleased at how the overflow of incoming submissions 
for 9.2 has raised questions around not having enough active committers.  I hope decisions about adding more recognizes
thatdistributing that 
 
power really does influence the ability of people to contribute, on 
average in a positive way.  All I see coming for next year is a dramatic 
increase in this class of problem.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com