All, So the proximate cause of late releases are the following:
1. patches are getting kicked down the road from one CF to another, creating a big pileup in the final CF. This is exactly like the huge pile of unreviewed patches we used to have before the CF system. 2. Once the last CF is closed, everyone goes off and starts working on the next version, leaving a few people to handle getting the production release integrated and debugged. This is partly because nobody likes doing that work, and partly because most hackers aren't clear how they can help. So, I have a modest suggestion on how to change all this: Let's do quarterly development releases and supported production releases every 18 months. A 3-month release cycle would let people see their code go into the wild a lot faster; basically we'd do a CF then a development release. That would limit pileup issues around people losing interest/moving on, forgetting what was going on, and conflicts between various features in development. A shorter release/dev cycle is more manageable. By having supported production releases 50% less often, we could keep the overall number of versions we need to patch the same as it is now. The alternative to this is an aggressive recruitment and mentorship program to create more major contributors who can do deep review of patches. But that doesn't seem to have happened in the last 5 years, and even if we started it now, it would be 2 years before it paid off. -- Josh Berkus Red Hat OSAS (opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
