Re: 8.4 release planning

On Tuesday 27 January 2009 18:51:01 Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
> > Now I am starting to think that we cannot prevent large patches from
> > showing up at the end of a cycle no matter what, and the only way to
> > really "solve" that problem is to lesson the pain of getting bumped from
> > a release. Ie. instead of being bump meaning you must wait 12-14 months
> > till next release, we move toward more of a 6 month cycle of development.
>
> I really can't see going in that direction.  In the first place, no one
> wants to spend a third or more of the time in beta mode. 

Yeah, I was thinking that, but the truth is we do that now. We released last 
Febuary right? and we're looking at releasing (optimisttically) May 1st, 
right? So thats 15months, of which November - May (6 months) will have been 
feature freeze / beta / rc phase of development.   

> In the 
> second place, if the problem is big patches that take a long time to
> develop, halving the length of the development cycle is no solution.
> (If it did work, our plea to break large patches into segments landing
> in different commitfests would have had more results.) 

I think this is a mis-assesment of our problem. The problem is not that big 
patches take a long time; not so much that they don't, just that is not a 
problem we can solve... "Hey Simon, code faster!" is not going to work ;-) 

The problem is that the pain point is extremely high for missing a given 
release cycle. If you don't make a specific release, you have a 12-14 month 
wait for feature arrival. Given that choice, someone who deperately need (aka 
wants) HS/SEPostgres/Win32/HOT/IPU/etc... will likely be willing to push a 
release 3-6 months for that one feature. 

Incidentally, this is probably why people didnt worry about making a given 
commitfest. The pain point was low, so there was no percieved need to rework 
a patch for a specific commit, since there was another one just a couple 
months away. However, we still see a rush of patches at the final freeze 
because people know that "there is no tommorrow" at that point.  

> In the third 
> place, unless we get an upgrade-in-place process that works all the
> time, we would be looking at maintaining twice as many back branches
> in order to provide the same kind of release lifespan we have today.
> We are at the limit of what we can realistically do in back-branch
> maintenance already :-(
>

Yeah, I can't argue with that. I'm not sure it's an unsolvable problem though; 
if odd/even release maintenance doesn't sound good, we could do something 
like ubuntus LTS, where we pick 1 release every 3 years to make a long-term 
support commitment (I think 5 years is our current max), and keep other 
releases on a shorter lifespan (1 or 2 years). Certainly having IPU (or is 
that UIP?) would make that an easier decision.  
-- 
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com