Skip site navigation (1) Skip section navigation (2)

Re: Feature freeze progress report

From: Dave Page <dpage(at)postgresql(dot)org>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Feature freeze progress report
Date: 2007-04-30 11:56:35
Message-ID: 4635D973.90106@postgresql.org (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-www
Bruce Momjian wrote:
> Tom Lane wrote:
>> Dave Page <dpage(at)postgresql(dot)org> 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.
> 
> I am still unclear how the patch would get into such a system, and how
> we would add comments, apply, and later remove it, without causing us
> even more work.
> 

In my original message I described my thinking:

- Developer submits patch, with additional info through a web interface.

- The web interface formats an email containing the patch description,
patch and any other info entered, assigns it a patch number, and
forwards it to the patches list.

- Discussion ensues on list as per normal. The tracking system monitors
the list and automatically attaches any posts to the patch that have the
appropriate reference in the subject line.

- Community members and committers can review the entire discussion
through the systems web interface. Updated patches could be submitted
online.

- Committers log into the system when necessary to alter the status
(committed, rejected, awaiting revision, under review etc), or the queue
name (8.3, 8.4 etc). This could also be done automagically via email
keywords from specific addresses.

You would no longer need to manually manage the queue, and the
committers would simply need to tweak the status flag as required.

Regards, Dave

In response to

Responses

pgsql-www by date

Next:From: Dave PageDate: 2007-04-30 12:00:31
Subject: Re: Feature freeze progress report
Previous:From: Andrew DunstanDate: 2007-04-30 11:54:40
Subject: Re: Feature freeze progress report

pgsql-hackers by date

Next:From: Dave PageDate: 2007-04-30 12:00:31
Subject: Re: Feature freeze progress report
Previous:From: Andrew DunstanDate: 2007-04-30 11:54:40
Subject: Re: Feature freeze progress report

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group