Robert Haas wrote: > Both committers and non-committers are currently suffering from the > fact that there is not a lot of time in the year which is set aside > for development, i.e. neither CommitFest-time nor beta-time. To fix > this problem, we can: > > 1. Make CommitFests shorter. > 2. Make CommitFests less frequent. > 3. Continue developing during CommitFests. > 4. Make beta cycles shorter. > 5. Make beta cycles less frequent (i.e. lengthen the release cycle). > 6. Continue developing during beta. > > I believe (1) to be completely impractical and (3) to be > self-defeating. I suspect (2) will backfire badly. That doesn't > leave us with a lot of options. We can certainly do (5), but the > downside is that features that get committed won't hit release for a > very long time. I and others have suggested a couple of possible > approaches toward (4) or (6), such as changing the way we do release > notes, adding more regression tests to give us more (not perfect) > confidence that the release is solid, and/or branching the tree during > beta. None of those ideas have gotten a single vote of confidence > from you or Bruce. What's your suggestion?
Another solution would be to make major releases less frequent. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
