Re: Feature freeze progress report - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Feature freeze progress report
Date
Msg-id 87k5vrh1wg.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Feature freeze progress report  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Feature freeze progress report  (Bruce Momjian <bruce@momjian.us>)
Re: Feature freeze progress report  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Bruce Momjian" <bruce@momjian.us> writes:

> We seem to handle trivial patches just fine.  

You keep saying that but I think it's wrong. There are trivial patches that
were submitted last year that are still sitting in the queue.

In fact I claim we handle complex patches better than trivial ones. HOT, LDC,
DSM etc receive tons of feedback and acquire a momentum of their own.
Admittedly GII is a counter-example though.

On the other hand trivial patches tend to interest relatively few people and
have little urgency.

> The current problem is that the remaining patches require domain or
> subsystem-specific knowledge to apply, e.g. XML or WAL, and those skills are
> available in a limited number of people. If I had the expertise in those
> areas, I would have applied the patches already.

Well, I claim it's often the trivial patches that require the domain-specific
knowledge you describe. If they were major patches they would touch more parts
of the system. But that means they should be easy to commit if you could just
fill in the missing knowledge.

Could you pick a non-committer with the domain-specific knowledge you think a
patch needs and ask for their analysis of the patch then commit it yourself?
You can still review it for general code quality and trust the non-committer's
review of whether the domain-specific change is correct.
--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Patch queue triage
Next
From: Gregory Stark
Date:
Subject: Re: Heap page diagnostic functions