Re: 8.3 pending patch queue - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: 8.3 pending patch queue
Date
Msg-id 20070109202640.GC11064@alvh.no-ip.org
Whole thread Raw
In response to Re: 8.3 pending patch queue  (Bruce Momjian <bruce@momjian.us>)
Responses Re: 8.3 pending patch queue  (Bruce Momjian <bruce@momjian.us>)
Re: 8.3 pending patch queue  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > 
> > > The hold queue has patches that still need discussion, or ideas for
> > > patches, so it is more than just patches ready for application, and
> > > moving the whole thing at once would overwhelm patch reviewers.
> > 
> > So why aren't all patches that are posted to the -patches list in the
> > hold queue?
> 
> Because I haven't looked them over yet, and wasn't putting things in the
> queue while we were waiting on 8.2.1.

No, I mean in principle, not in this particular case.  If we have two
queues, and there's a barrier to moving patches from the "hold" queue to
the other queue, why aren't patches posted in pgsql-patches put right
away in the "hold" queue?

After all, there's already a barrier to applying a patch in the non-hold
queue, which is that someone reviews and approves it.  Does it make
sense to have three barriers to the patch managing process?  ISTM two is
good enough (first when moving a patch from the hold queue to the main
queue, and then when applying a patch from the main queue).

I hope I'm making sense here :-)

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: 8.3 pending patch queue
Next
From: Josh Berkus
Date:
Subject: Dynamically sizing FSM?