Chris Browne <cbbrowne@acm.org> writes:
> josh@agliodbs.com (Josh Berkus) writes:
>> In fact, I could see doing a "no-catalog-changes, no major patches we don't
>> already know about, 6-month release". It would reset our cycle and get
>> PL/proxy, DSM, clustered indexes, etc. out the door. It could mean
>> turning away patches which look attractive, though, so the whole community
>> has to be into this.
> There are good things about that idea.
> There would also be good things about picking a somewhat *longer*
> cycle in that we already just had a cycle where the "feature freeze"
> period was supposedly a short one, which precluded implementing
> anything requiring more planning.
[ chewing on this a bit... ] The curious thing about that is that
despite this being designed to be a short release cycle, we ended up
landing a bunch of major patches that weren't on the radar screen at
all at the start of the cycle. This suggests to me that there's
something wrong with the concept that no one can get anything major done
without a long release cycle to do it in.
Indeed, the thing that seemed to me to be killing us in this freeze
cycle was that the patches coming in were already at the upper limit of
what we can review and digest. I don't think I want to say "okay guys,
we'll give you a year so that you can write a 200K-line patch and drop
it on us the day before feature freeze".
I'd rather encourage people to work in an incremental, not-so-big-bang
fashion. Obviously one of the requirements for that will be quicker
review turnaround and commit, so that there's time to build on a
previous patch...
regards, tom lane
