On 2016-01-20 11:53:32 -0500, Robert Haas wrote: > But I'm not very sure that we're talking about the same set of people > here. If we're going to go to a system where nobody's allowed to > commit anything for the next release until the current release is > finalized, then we'd better have some procedure for making sure that > happens relatively quickly. And the procedure can't be that the > people who are hot to get started on the next release have to bat > cleanup for the people who don't have time to fix the bugs they > introduced previously. Because *that* would be manifestly unfair.
Yes, that's a problem. But I don't see how we can avoid dealing with it directly. Avoiding being stalled by unfixed bugs of others by having a separate branch to continue working, inevitably leads to delayed releases. If people don't fix the issues in time, there needs to be direct pushback, leading to much less stuff getting in next time round. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
