From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Feature Freeze date for 8.4 |
Date: | 2007-10-24 01:55:40 |
Message-ID: | 19950.1193190940@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> It might be worth applying a simple tag (but not a branch) at the end
> (and maybe also at the start) of each checkpoint/fest/whatever
Perhaps, though of course one could easily enough pull a CVS snapshot by
date instead (especially if we stick to a pretty predictable schedule
for the fests).
Thinking about that a bit more, it seems like a rigid "two weeks" plan
is pointless, since the amount of work to be done will vary depending
on what's in the queue. It seems what we ought to do is something like
this:
* Commit-fest starts on the first of each alternate month. It ends
whenever all the patches that were in the queue on the first are dealt
with; either committed, rejected permanently, or sent back for specific
rework. It might take a week, or two, or three, but in any case we all
try to focus on patch review rather than new work until it's done.
If we do it that way, then an end-of-fest tag might be worthwhile,
so you'd not have to dig through the mailing list archives to figure out
when a fest ended.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2007-10-24 02:56:08 | Re: Feature Freeze date for 8.4 |
Previous Message | Andrew Dunstan | 2007-10-24 01:34:04 | Re: Feature Freeze date for 8.4 |