On Thu, Apr 21, 2011 at 11:16 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut <pete...@gmx.net> wrote: >>> I think to really address that problem, you need to think about shorter >>> release cycles overall, like every 6 months. Otherwise, the current 12 >>> to 14 month horizon is just too long psychologically. > >> I agree. I am in favor of a shorter release cycle. > > I'm not. I don't think there is any demand among *users* (as opposed to > developers) for more than one major PG release a year. It's hard enough > to get people to migrate that often.
I agree there's probably little user demand, and back-branch maintenance is an issue, but I think if it removed the temptation to cram major new features into the tree at the last minute, it might be worth it. However, a possibly more likely outcome is that we'd still have that temptation, just more frequently; and end up with even less of the year open to new patches than is currently the case. > Another problem is that if you halve the release interval, you either > double the amount of work spent on maintaining back branches, or halve > the support lifetime of a branch. Neither of those is attractive. > > Now, it certainly would be nice to spend less time in beta mode as > opposed to development, and I think most of the points being made here > are really about how to cut that. But reducing the release interval is > not going to reduce the total amount of time we spend in beta mode; > in fact I'd expect it to increase. Halving the amount of development > time per release doesn't mean that you can cut beta time proportionally. > It just takes time to cut a release, and time for testers to try it. I believe that the problem is much more related to the fact that we commit things at the end of the cycle that aren't really done than it is to the amount of time beta testers need to try things. If we were only waiting on testing, we could branch the tree and call the release du jour beta for another N months, then release, meanwhile continuing development. In fact, you and I and three or four other people have spent most of our visible PG time over the last 2 months fixing MANY bugs, mostly in the six or so major features committed between February 7th and March 6th. (By way of comparison, notice how few bugs that have been in the major patches from CF3 - because those things were actually pretty much working *when they were committed*.) Now, we're getting to the point where that might actually be a reasonable way to go. It wouldn't bother me a bit to branch the tree just after beta1 and start a new cycle of CommitFests on May 15th, and we could begin integrating some of the big stuff that didn't make it into 9.1: key locks, range types, additional sync rep modes, snapshot cloning, parallel pg_dump, etc. It would be great to start working on that stuff while it's still mildly fresh in people's minds, and at the *beginning* of the release cycle. We're probably doomed to another fall release at this point anyway, so it's not clear to me that the inevitable loss of focus that will ensue is really costing anything. Had we gotten to beta1 on March 1st, I'd probably be in favor of going all in to get the release out in June or maybe on July 1, but at this point that seems unlikely to be realistic. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
