On Thu, Apr 21, 2011 at 11:05 AM, Robert Haas <robertmh...@gmail.com> wrote: > I agree. I am in favor of a shorter release cycle. But I think that > a shorter release cycle won't work well if there is still four month > long integration period at the end of each series of CommitFests. The > problem is a bit circular here: because release cycles are long, > people really, really want to slip as much as possible in at the end. > But being under time pressure to get things committed results in a > higher bug count, which means more things that have to be fixed after > feature freeze, which translates into a long release cycle.
If we somehow were able to come up with a 6 week release cycle, we'd still have the problem that there are features that take more than 6 weeks to integrate into a release. (HOT and SyncRep, I'm looking at you!) Any such larger features would "blow this up," quite forcibly. I don't think our release cycle is vastly too long; it takes enough time to plan upgrades for systems that my colleagues at Afilias aren't keen on using every PG release in production that comes out as it stands now. Peter Eisentraut points out that with the way things are, now, "... you are left with all of about 20 days per year for discussion, collaborative planning and coding. Which is obviously silly, which is why the process breaks down." I think the CommitFests have been a *super* tool for addressing such problems as: - patches getting lost - getting review effort put onto the easier patches But they aren't the only thing we conceptually need to have. For tougher features, they're not great. And they're completely useless at addressing discussions surrounding things we know we want done, but don't have a strategy for yet. Those things aren't "patches", there's nothing yet to commit. My sense is that something else is needed as a process to help with those "nebulous large changes." I'm not sure quite what it looks like. Maybe there's some tooling that would be helpful, but we really need some experimentation to figure out what the process should look like. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers