Robert Haas <robertmh...@gmail.com> wrote: > The recent and wide-ranging "formatting curmudgeons" thread > included suggestions by Tom and myself that we should consider > branching the tree immediately after beta1. My take is that it should be branched as soon as a committer would find it useful to commit something destined for 9.2 instead of 9.1. If *any* committer feels it would be beneficial, that seems like prima facie evidence that it is needed, barring a convincing argument to the contrary. > The other major issue discussed on the thread was as to how > frequent and how long CommitFests should be. > On balance, I think I prefer the current arrangement, though if we > could make the CommitFests a bit shorter I would certainly like > that better. I don't know how to make that happen without more > reviewers, though. Agreed. It is hard to picture doing shorter commit fests without that just pushing more of the initial review burden to the committers. Besides the normal "herding cats" dynamic, there is that matter of schedules in an all-volunteer project. When I've managed CFs, there have been people who were on vacation or under the deadline to complete a major paper during the first week of the CF who were able to contribute later. Some non-committer reviewers were able to complete review of one patch and move on to others. During the weeks of a single CF some patches go through multiple critiques which send them back to the author, so I'm not sure how much a shorter cycle would help with that issue for non-committer reviews. Perhaps we will get some of the stated benefits of shorter CF cycles as reviewers become more skilled and patches get to the reviewers with fewer problems. Maybe we could encourage reviewers to follow patches which they have moved to "Ready for Committer" status, to see what the committers find that they missed, to help develop better skills. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers