> -----Original Message-----
> From: Jason Earl [mailto:jason.earl@simplot.com] 
> Sent: Friday, June 20, 2003 10:45 AM
> To: The Hermit Hacker
> Cc: Robert Treat; Tom Lane; Christopher Kings-Lynne; Bruce 
> Momjian; PostgreSQL-development
> Subject: Re: [HACKERS] Two weeks to feature freeze
> 
> 
> The Hermit Hacker <scrappy@postgresql.org> writes:
> 
> > On Thu, 19 Jun 2003, Robert Treat wrote:
> >
> >> Well, I suppose that history has shown that waiting on specific 
> >> features causes trouble with postgresql development, but I 
> don't see 
> >> why a release can't be based around waiting for feature x 
> as long as 
> >> feature x is being actively worked on by trusted 
> developers who have 
> >> an endgame in sight.
> >
> > Everyone has an 'endgame in sight', at least when they ask for a 
> > release to be postponed ... but then their date keeps slipping, etc 
> > ...
> >
> > The thing is, if win32 is 'that close to being finished', 
> then as soon 
> > as v7.4 is out, that code should be ready to throw in ... 
> and the same 
> > for every other features that could 'postpone a release' ...
> >
> > I'd rather see the dev cycle shortened by a month, then extended ...
> 
> Why couldn't you just release the win32 version of 7.4 when 
> it was finished.  If it takes an extra month then that just 
> gives you guys the chance to circulate *two* press releases.  
> The Native Win32 port is likely to make a big enough splash 
> all by itself.

A formal release needs a big testing effort.  Two separate releases will
double the work of validation.

Fri, 20 Jun 2003 11:46:57 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: Two weeks to feature freeze
Dann Corbit wrote:
> > -----Original Message-----
> > From: Jason Earl [mailto:jason.earl@simplot.com] 
> > Sent: Friday, June 20, 2003 10:45 AM
> > To: The Hermit Hacker
> > Cc: Robert Treat; Tom Lane; Christopher Kings-Lynne; Bruce 
> > Momjian; PostgreSQL-development
> > Subject: Re: [HACKERS] Two weeks to feature freeze

[...]

> > Why couldn't you just release the win32 version of 7.4 when 
> > it was finished.  If it takes an extra month then that just 
> > gives you guys the chance to circulate *two* press releases.  
> > The Native Win32 port is likely to make a big enough splash 
> > all by itself.
> 
> A formal release needs a big testing effort.  Two separate releases will
> double the work of validation.

That's true in the general case.

But in this case we're talking about releasing for a completely new
platform.  That's much different than doing another release for the same
platform set.

The testing that needs to be done for the Win32 release has to be done
separately *anyway*, so there's nothing lost by releasing the Win32 port
separately.


-- 
Kevin Brown					      kevin@sysexperts.com

Fri, 20 Jun 2003 15:02:56 -0700
Kevin Brown <kevin@sysexperts.com>
Re: Two weeks to feature freeze
"Dann Corbit" <DCorbit@connx.com> writes:
>> 
>> Why couldn't you just release the win32 version of 7.4 when 
>> it was finished.  If it takes an extra month then that just 
>> gives you guys the chance to circulate *two* press releases.  
>> The Native Win32 port is likely to make a big enough splash 
>> all by itself.
>
> A formal release needs a big testing effort.  Two separate releases
> will double the work of validation.

There are several problems with that statement.  The first is that
PostgreSQL's "testing effort" happens right here on this mailing list.
The various PostgreSQL hackers code stuff up, and we try and break it.
There's very little /effort/ involved.  People that want the new
features go out on a limb and start using them.  If they don't work,
then they bring it up on the list.  If they do work then very little
gets said.

As it now stands Tom Lane is on the record as stating that the new
Win32 version isn't going to be ready for production anyhow.  If
anything the Win32 version *should* get released separately simply
because we don't want people mistaking the Win32 version as being up
to the PostgreSQL teams high standards.  Those people that want the
Win32 version to become production ready are going to have to risk
their precious data.  Otherwise, the Win32 version will likely remain
a second class citizen forever.

The fact of the matter is that the Win32 specific bits are the parts
that are likely to break in the new port.  If anything the Windows
version will *benefit* from an earlier *nix release because the *nix
users will chase down the bugs in the new PostgreSQL features.  Once
the *nix version is up to 7.4.2 (or so) then a Windows release of
7.4.2 should allow the PostgreSQL hackers to simply chase down Windows
specific problems.

Adding a new platform--especially a platform as diverse from the rest
of PostgreSQL's supported platforms as Windows--is what adds the work.
Testing the new platform is relatively easy.  All you need to do is to
start using the Win32 version with real live data.

Jason

Fri, 20 Jun 2003 16:31:31 -0600
Jason Earl <jason.earl@simplot.com>
Re: Two weeks to feature freeze
Jason Earl <jason.earl@simplot.com> writes:
> The fact of the matter is that the Win32 specific bits are the parts
> that are likely to break in the new port.

Actually, what scares me about this is the probability that the Win32
port will break other platforms.  The changes look to be invasive enough
to create a nontrivial risk of that.

For comparison, look at the CVS history of the recent efforts to support
IPv6 connections.  Those patches have broken both IPv4 and Unix-socket
connections at different times, and are still a source of ongoing build
problems on some platforms, plus who-knows-what problems yet to be found
on platforms that aren't used by the bleeding-edge-CVS folk.  I predict
that the tweaks needed to support Windows' lack of a fork() primitive
will be far worse.

BTW, I would not approve of a response along the lines of "can't you
#ifdef to the point that there are no code changes in the Unix builds?"
No you can't, unless you want to end up with an unmaintainable mess 
of #ifdef spaghetti.  The thing that makes this hard is the tradeoff
between making the code readable and maintainable (which requires
sharing as much code as possible across platforms) vs isolating
platform-specific considerations.  Programming at this level is not
a science but an art form, and it's very hard to get it right the first
time --- especially when none of us have access to all the platforms
that the code must ultimately work on.

			regards, tom lane

Fri, 20 Jun 2003 23:32:34 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Two weeks to feature freeze 
Tom Lane wrote:
> BTW, I would not approve of a response along the lines of "can't you
> #ifdef to the point that there are no code changes in the Unix builds?"
> No you can't, unless you want to end up with an unmaintainable mess 
> of #ifdef spaghetti.  The thing that makes this hard is the tradeoff
> between making the code readable and maintainable (which requires
> sharing as much code as possible across platforms) vs isolating
> platform-specific considerations.  Programming at this level is not
> a science but an art form, and it's very hard to get it right the first
> time --- especially when none of us have access to all the platforms
> that the code must ultimately work on.

Exactly my point and the reason I am doing the entire fork+exec stuff 
over again. Bruce nagged me endlessly to commit the broken parts I had 
and fix them later. I never agreed with that philosophy because in my 
experience the worst workarounds live forever.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


Sun, 22 Jun 2003 08:07:10 -0400
Jan Wieck <JanWieck@Yahoo.com>
Re: Two weeks to feature freeze
Jan Wieck wrote:
> Tom Lane wrote:
> > BTW, I would not approve of a response along the lines of "can't you
> > #ifdef to the point that there are no code changes in the Unix builds?"
> > No you can't, unless you want to end up with an unmaintainable mess 
> > of #ifdef spaghetti.  The thing that makes this hard is the tradeoff
> > between making the code readable and maintainable (which requires
> > sharing as much code as possible across platforms) vs isolating
> > platform-specific considerations.  Programming at this level is not
> > a science but an art form, and it's very hard to get it right the first
> > time --- especially when none of us have access to all the platforms
> > that the code must ultimately work on.
> 
> Exactly my point and the reason I am doing the entire fork+exec stuff 
> over again. Bruce nagged me endlessly to commit the broken parts I had 
> and fix them later. I never agreed with that philosophy because in my 
> experience the worst workarounds live forever.

I wouldn't say nagging ... I would say NAGGING.  :-)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sun, 22 Jun 2003 09:30:45 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Two weeks to feature freeze