Simon Riggs <[email protected]> writes:
> On 4 February 2013 21:48, Dave Page <[email protected]> wrote:
>> We should really freeze the code for 24 hours shouldn't we? That way
>> we know most, if not all of the buildfarm animals will have had a
>> chance to go red since the last code change.
> Do whatever you like, as long as you tell me about it.
No, the problem here is *you* didn't tell anybody what you were doing.
If it was something that would have merited a release postponement,
we could easily have done that. But cramming unreviewed code into
a release at the last moment is a sure path to trouble.
As Dave says, one reason to avoid that is lack of buildfarm testing.
If you're pretty confident that a patch couldn't possibly have any
portability issues, then maybe a full buildfarm cycle isn't necessary;
but I think at least 6 or 8 hours is a good idea to give time for some
amount of sanity checking from the farm.
Another problem is that it takes time (and not a small amount of it) to
prepare the release notes. I've been head-down on the release notes and
other details of the wrapping process since about six hours ago, and
would not have appreciated a last-minute commit that I needed to account
for in the notes.
We've never had, or particularly wanted, a formal policy about
pre-release code freezes. But if you're going to start pushing the
boundaries of what's safe, maybe we will have to have one.
regards, tom lane
--
Sent via pgsql-committers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
