public inbox for [email protected]  

help / color / mirror / Atom feed

From: Dave Page <[email protected]>
To: Tom Lane <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Simon Riggs <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Feature freeze progress report
Date: Mon, 30 Apr 2007 08:32:48 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Tom Lane wrote:
> Dave Page <[email protected]> writes:
>> I like the idea of having a sync point mid cycle, however, what I'd like 
>> to see even more is an improved system in which we put less pressure on 
>> the few committers we have, and give them more freedom to commit patches 
>> they may not understand fully themselves
> 
> That is a recipe for disaster :-(.  The real problem I see with the big
> patches that are currently in the queue is that I'm not sure even the
> authors understand the patches (or more accurately, all their potential
> consequences) completely.  Telling committers they should apply such
> patches without having understood them either is just going to lead to
> an unfixably broken system.
> 
> [ thinks for a bit... ]  What we need to expand is not so much the pool
> of committers as the pool of reviewers.  If a patch had been signed off
> on by X number of reasonably-qualified people then it'd be fair to
> consider that it could be committed.  The tracking system you suggest
> could make that sort of approach manageable.

Err, I thought that was precisely what I was suggesting in my second
point :-). To reiterate:

- Expand the pool of committers (slowly, and as appropriate - not for
the sake of it). There inevitably is and will continue to be more work
for experienced committers. We should consider 'promoting' those
developers that become experienced and trusted.

- Use a tracking system to enable the committers to rely more on the
experience of the users. Ideas we have discussed here in the office
~(which I didn't mention earlier) included a scoring system, where
trusted developers (who aren't necessarily committers) can score patches
or veto them if there are real problems spotted and to highlight the
comments from those experienced people to make it easy to spot what they
say.

Regards, Dave.

view thread (98+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Feature freeze progress report
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox