Re: [HACKERS] Release planning (was: Re: Status report)

2004-07-14 Thread Josh Berkus
Jan,

 What touches me here is the fact that the PostgreSQL Open Source Project
 under the BSD license seems starting to care a lot more about some press
 releases and silly news splashes, than to care about real features
 contributed under the terms and conditions of the BSD license by serious
 members of the Open Source Community. 

I don't get this.  At what point did you seriously expect that 7.5 would be 
out less than a year after 7.4?   

The only circumstance I can recall discussing on -Core under which PG7.5 would 
be released early was if Win32 was ready and debugged by March.   
Otherwise, I was certainly expecting that things would go more or less as 
they did last year (though hopefully with more bugs caught during beta) and 
nothing we discussed here or on -Core led me to think otherwise.

I do agree that the fact that, for example, NTs have gotten press coverage is 
*no* reason to decide whether to keep them for 7.5 or push them to 7.6.   
Press coverage exists to enhance the image of PostgreSQL and not to influence 
development.   Nor is the fact that FJ sponsored the feature in question 
significant; if they want it ASAP, they can afford to backport.

No, the questions which are important are the below.  And keep in mind that 
the *only* patch we're talking about holding back is NTs; so far, nobody has 
raised any issues with PITR or Tablespaces that would prevent them from being 
part of 7.5.0.

1) How long is it going to take to resolve the remaining issues with NTs?  It 
this a next week thing or is this like Win32, last year?

2) Are the unresolved issues with NTs the result of the complexity of the 
problem, or just the result of the community not paying attention to the 
patch until after feature-freeze?

3) Is there some majority in our community who would rather hold back 7.5 by 
several weeks in order to get NTs now instead of mid-2005?

Based on (1) and (2), NTs are starting to feel like Win32 did last year to me.  
Please don't mistake me; I would very, very much like to have them as someone 
with half a million lines of PL/pgSQL in my past and half-a-dozen 
J2EE+PostgreSQL clients.   It's a very hard problem and Alvaro has been 
working like a demon to resolve it.

However, I'm beginning to think that it is a *very* hard problem and Alvaro 
has had only about 2 months to work on it.   There are just too many things 
-- cursors, functions, exceptions, syntax -- that we have only begun to 
address.   I'm very much afraid of a repeat of last year, where we waited an 
extra month for a Win32 version that was going to take an extra year.

So I'm thinking we hold them back.  That we try to get out 7.5 by October this 
year, and target 7.6, on a short release cycle, for March.  We would already 
have 3 new features for 7.6, and I'm sure more will show up by January.   
This would also resolve the issue of shifting our release cycles.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [HACKERS] Release planning (was: Re: Status report)

2004-07-14 Thread Gaetano Mendola
Bruce Momjian wrote:
I was thinking of something much simpler where Jan would create an ARC
patch against 7.4.X and have it either in /contrib for 7.4.X or on our
ftp servers, or on a web site.  I could create a mechanism so SELECT
version() would display Jan's add-on.
:-(
I was asking to add the vacuum delayed patch to 7.4 months ago and the response
was: why introduce instability to a stable release ?
I hope the global consensus is a no way to procede also for ARC.
It's true the version 7.5 ( or 8.0 ) will be really a great release but
IMHO introduce in one shot:
1) PITR
2) Nested Transaction
3) WIN32 porting
4) ARC
5) Table Space
6) I'm sure I'm forgetting something
was really too much.
I hope that all will be fine.
Regards
Gaetano Mendola



---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
 joining column's datatypes do not match