Re: Feature freeze progress report

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Naz Gassiep <naz(at)mira(dot)net>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Marc Munro <marc(at)bloodnok(dot)com>, heikki(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org, dpage(at)postgresql(dot)org, simon(at)2ndquadrant(dot)com, bruce(at)momjian(dot)us
Subject: Re: Feature freeze progress report
Date: 2007-05-02 05:10:31
Message-ID: 5592.1178082631@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Naz Gassiep <naz(at)mira(dot)net> writes:
> Andrew Dunstan wrote:
>> How do we know in advance of reviewing them that they are sane?

> Same way as happens now. I would assume this mechanism would only be
> applied to patches that had already been approved to contrib, or some
> other measure that can be used to isolate only those patches that we
> *expect* to already be working.

What is "approved to contrib"?

The problem here is that having reasonable certainty that a patch is
not malicious requires having gone over it in some detail; at which
point you might as well apply the thing. Or if you didn't apply it,
you bounced it for reasons that are unlikely to have anything to do
with needing more automated testing.

ISTM this idea can only work if we have a "second tier" of reviewers
who are considered good enough to vet patches as safe, but not quite
good enough to certify them as commitable. I'm not seeing a large pool
of people volunteering to hold that position --- at best it'd be a
transitory state before attaining committerdom. If you are relying
on a constant large influx of new people, you are doomed to failure
(see "Ponzi scheme" for a counterexample).

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-05-02 05:19:45 Re: Feature freeze progress report
Previous Message Josh Berkus 2007-05-02 04:51:51 Re: Feature freeze progress report