Re: Last gasp

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Last gasp
Date: 2012-04-11 00:43:12
Message-ID: 4F84D3A0.8010808@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 is still 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 that distributing 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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-04-11 00:47:28 Re: pg_tablespace_location() error message
Previous Message Tom Lane 2012-04-11 00:30:31 Re: pg_tablespace_location() error message