Josh Berkus <j...@agliodbs.com> writes:
>> Huh? We've never guaranteed anyone a regular annual cycle, and we've
>> never had one. We agreed to use the same schedule for 9.1 as for 9.0;
>> I don't remember anything more than that being discussed anywhere,
>> ever.
> We *want* to have a regular annual cycle which doesn't vary by more than
> a few weeks.
There may be some people who want that, but it's not project policy
and I don't think it will ever become so. Our policy is "we release
when it's ready". To allow the development schedule to become purely
calendar-driven would mean a drastic decline in our quality standards.
I suppose we could have something like a predetermined branch-from-devel
date for each major release, with the time from branch to actual release
varying depending on release stabilization progress, while new
development proceeds forward on a regular commitfest clock. But I fail
to see any significant advantage from doing that. What it would mostly
do is decouple the development community entirely from release
stabilization work, and I think that would be a seriously bad idea.
Not only from the take-responsibility-for-your-work angle, but because
diverting manpower from release stabilization will also mean that it's
that much longer from feature freeze (or whatever you call the branch
event) to actual release. I don't think that people will be that happy
about knowing "if I finish this by date X, it will be in release N" if
they have no idea when release N will reach production status.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
