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 (
To make changes to your subscription:

Reply via email to