Marc G. Fournier wrote:
> > > No, I agree that that would be foolish ... but there has also been alot
> > > done on the code over the past few months that even *one* of those
> > > features should be enough to put it over the top ...
> >
> > OK, what is the plan for feature freeze?
> >
> > As we going for June 1, and making no adjustments?  If we have no major
> > features done, we still do June 1.  Or are we waiting for one or several
> > major features to complete and then set a freeze date?
> 
> 1 of the major features that are currently on tap (ie. Win32) *or* June
> 1st, whichever happens to be the longer of the two ...
> 
> Indications that I've seen through this discussion are that Win32 can, and
> should, be done by June 1st ...so extending may be a moot point anyway ...

OK, but I am worried about giving Win32 special treatment, and having
the date float like that until Win32 is done.  This is what we did with
the SMP fixed in 7.3 and the date slipped week by week.  We have to set
the date firm early on.  I think we all agreed to that in the past.

-- 
  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

Fri, 30 Apr 2004 15:15:26 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Plan for feature freeze?
On Fri, 30 Apr 2004, Bruce Momjian wrote:

> Marc G. Fournier wrote:
> > > > No, I agree that that would be foolish ... but there has also been alot
> > > > done on the code over the past few months that even *one* of those
> > > > features should be enough to put it over the top ...
> > >
> > > OK, what is the plan for feature freeze?
> > >
> > > As we going for June 1, and making no adjustments?  If we have no major
> > > features done, we still do June 1.  Or are we waiting for one or several
> > > major features to complete and then set a freeze date?
> >
> > 1 of the major features that are currently on tap (ie. Win32) *or* June
> > 1st, whichever happens to be the longer of the two ...
> >
> > Indications that I've seen through this discussion are that Win32 can, and
> > should, be done by June 1st ...so extending may be a moot point anyway ...
>
> OK, but I am worried about giving Win32 special treatment, and having
> the date float like that until Win32 is done.  This is what we did with
> the SMP fixed in 7.3 and the date slipped week by week.  We have to set
> the date firm early on.  I think we all agreed to that in the past.

No no ... the date isn't floating on Win32 ... the date is floating on one
of the major features (PITR, 2PC, etc) ... if Win32 happens to be the
first major feature, so be it, but it is not contigent on Win32 ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Fri, 30 Apr 2004 17:54:06 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: Plan for feature freeze?
Marc G. Fournier wrote:
> On Fri, 30 Apr 2004, Bruce Momjian wrote:
> 
> > Marc G. Fournier wrote:
> > > > > No, I agree that that would be foolish ... but there has also been alot
> > > > > done on the code over the past few months that even *one* of those
> > > > > features should be enough to put it over the top ...
> > > >
> > > > OK, what is the plan for feature freeze?
> > > >
> > > > As we going for June 1, and making no adjustments?  If we have no major
> > > > features done, we still do June 1.  Or are we waiting for one or several
> > > > major features to complete and then set a freeze date?
> > >
> > > 1 of the major features that are currently on tap (ie. Win32) *or* June
> > > 1st, whichever happens to be the longer of the two ...
> > >
> > > Indications that I've seen through this discussion are that Win32 can, and
> > > should, be done by June 1st ...so extending may be a moot point anyway ...
> >
> > OK, but I am worried about giving Win32 special treatment, and having
> > the date float like that until Win32 is done.  This is what we did with
> > the SMP fixed in 7.3 and the date slipped week by week.  We have to set
> > the date firm early on.  I think we all agreed to that in the past.
> 
> No no ... the date isn't floating on Win32 ... the date is floating on one
> of the major features (PITR, 2PC, etc) ... if Win32 happens to be the
> first major feature, so be it, but it is not contigent on Win32 ...

So you are floating the entire thing.  I am tired of discussing this. 
You call the freeze and when it is a disaster, you can take the credit.

I am not worrying about any freeze date anymore.  You freeze whenever
you want to.

Floating a freeze data has always been a failure.  Let's watch it happen
again.

-- 
  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

Fri, 30 Apr 2004 16:57:49 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Plan for feature freeze?
Hello,

Why don't we just set a freeze of August 1st? Give everyone just a 
little extra time. No float. If it doesn't make
it by August 1st, it doesn't make it.

This could also lead to other things. For example if we have Win32 and 
PITR calling it 7.5 is a mistake (IMHO) it should
be 8.0 etc...

Sincerely,

Joshua D. Drake


Sincerely,

Joshua D. Drake


Bruce Momjian wrote:

>Marc G. Fournier wrote:
>  
>
>>On Fri, 30 Apr 2004, Bruce Momjian wrote:
>>
>>    
>>
>>>Marc G. Fournier wrote:
>>>      
>>>
>>>>>>No, I agree that that would be foolish ... but there has also been alot
>>>>>>done on the code over the past few months that even *one* of those
>>>>>>features should be enough to put it over the top ...
>>>>>>            
>>>>>>
>>>>>OK, what is the plan for feature freeze?
>>>>>
>>>>>As we going for June 1, and making no adjustments?  If we have no major
>>>>>features done, we still do June 1.  Or are we waiting for one or several
>>>>>major features to complete and then set a freeze date?
>>>>>          
>>>>>
>>>>1 of the major features that are currently on tap (ie. Win32) *or* June
>>>>1st, whichever happens to be the longer of the two ...
>>>>
>>>>Indications that I've seen through this discussion are that Win32 can, and
>>>>should, be done by June 1st ...so extending may be a moot point anyway ...
>>>>        
>>>>
>>>OK, but I am worried about giving Win32 special treatment, and having
>>>the date float like that until Win32 is done.  This is what we did with
>>>the SMP fixed in 7.3 and the date slipped week by week.  We have to set
>>>the date firm early on.  I think we all agreed to that in the past.
>>>      
>>>
>>No no ... the date isn't floating on Win32 ... the date is floating on one
>>of the major features (PITR, 2PC, etc) ... if Win32 happens to be the
>>first major feature, so be it, but it is not contigent on Win32 ...
>>    
>>
>
>So you are floating the entire thing.  I am tired of discussing this. 
>You call the freeze and when it is a disaster, you can take the credit.
>
>I am not worrying about any freeze date anymore.  You freeze whenever
>you want to.
>
>Floating a freeze data has always been a failure.  Let's watch it happen
>again.
>
>  
>


-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL








Hello,

Why don't we just set a freeze of August 1st? Give everyone just a
little extra time. No float. If it doesn't make
it by August 1st, it doesn't make it.

This could also lead to other things. For example if we have Win32 and
PITR calling it 7.5 is a mistake (IMHO) it should
be 8.0 etc...

Sincerely,

Joshua D. Drake


Sincerely,

Joshua D. Drake


Bruce Momjian wrote:

Marc G. Fournier wrote:
  

On Fri, 30 Apr 2004, Bruce Momjian wrote:

    

Marc G. Fournier wrote:
      



No, I agree that that would be foolish ... but there has also been alot
done on the code over the past few months that even *one* of those
features should be enough to put it over the top ...
            

OK, what is the plan for feature freeze?

As we going for June 1, and making no adjustments?  If we have no major
features done, we still do June 1.  Or are we waiting for one or several
major features to complete and then set a freeze date?
          

1 of the major features that are currently on tap (ie. Win32) *or* June
1st, whichever happens to be the longer of the two ...

Indications that I've seen through this discussion are that Win32 can, and
should, be done by June 1st ...so extending may be a moot point anyway ...
        

OK, but I am worried about giving Win32 special treatment, and having
the date float like that until Win32 is done.  This is what we did with
the SMP fixed in 7.3 and the date slipped week by week.  We have to set
the date firm early on.  I think we all agreed to that in the past.
      

No no ... the date isn't floating on Win32 ... the date is floating on one
of the major features (PITR, 2PC, etc) ... if Win32 happens to be the
first major feature, so be it, but it is not contigent on Win32 ...
    


So you are floating the entire thing.  I am tired of discussing this. 
You call the freeze and when it is a disaster, you can take the credit.

I am not worrying about any freeze date anymore.  You freeze whenever
you want to.

Floating a freeze data has always been a failure.  Let's watch it happen
again.

  



-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
Fri, 30 Apr 2004 16:17:59 -0700
"Joshua D. Drake" <jd@commandprompt.com>
Re: Plan for feature freeze?
On Fri, 30 Apr 2004, Joshua D. Drake wrote:

> Hello,
>
> Why don't we just set a freeze of August 1st? Give everyone just a
> little extra time. No float. If it doesn't make
> it by August 1st, it doesn't make it.

We could go for September 1st, which would mean most are back from
holidays, in order to do beta testing ... and no, I'm not serious ...


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Fri, 30 Apr 2004 20:27:19 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: Plan for feature freeze?
>>Why don't we just set a freeze of August 1st? Give everyone just a
>>little extra time. No float. If it doesn't make
>>it by August 1st, it doesn't make it.
>>    
>>
>
>We could go for September 1st, which would mean most are back from
>holidays, in order to do beta testing ... and no, I'm not serious ...
>
>  
>
Why not? Seemed like a fairly good argument both yours and mine ;)

Sincerely,

Joshua D. Drake



>----
>Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
>Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664
>  
>


-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL












Why don't we just set a freeze of August 1st? Give everyone just a
little extra time. No float. If it doesn't make
it by August 1st, it doesn't make it.
    


We could go for September 1st, which would mean most are back from
holidays, in order to do beta testing ... and no, I'm not serious ...

  

Why not? Seemed like a fairly good argument both yours and mine ;)

Sincerely,

Joshua D. Drake





----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664
  



-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
Fri, 30 Apr 2004 16:33:55 -0700
"Joshua D. Drake" <jd@commandprompt.com>
Re: Plan for feature freeze?
On Fri, 30 Apr 2004, Joshua D. Drake wrote:

>
> >>Why don't we just set a freeze of August 1st? Give everyone just a
> >>little extra time. No float. If it doesn't make
> >>it by August 1st, it doesn't make it.
> >>
> >>
> >
> >We could go for September 1st, which would mean most are back from
> >holidays, in order to do beta testing ... and no, I'm not serious ...
> >
> >
> >
> Why not? Seemed like a fairly good argument both yours and mine ;)

To me, it ranks up there with "lets freeze someday in the future" ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Fri, 30 Apr 2004 21:21:09 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: Plan for feature freeze?
> > >>Why don't we just set a freeze of August 1st? Give everyone just a
> > >>little extra time. No float. If it doesn't make
> > >>it by August 1st, it doesn't make it.
> > >>
> > >>
> > >
> > >We could go for September 1st, which would mean most are back from
> > >holidays, in order to do beta testing ... and no, I'm not serious ...
> > >
> > >
> > >
> > Why not? Seemed like a fairly good argument both yours and mine ;)
> 
> To me, it ranks up there with "lets freeze someday in the future" ...

For me even September 1st does not seem too late. Major version up
bring users pains including backup/restore application
imcompatibilty... IMO to justify those pains we need to give users
major enhancements. Honestly I don't understand why we should rush the
major version up.
--
Tatsuo Ishii

Sat, 01 May 2004 09:53:50 +0900 (JST)
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: Plan for feature freeze?

>For me even September 1st does not seem too late. Major version up
>bring users pains including backup/restore application
>imcompatibilty... IMO to justify those pains we need to give users
>major enhancements. Honestly I don't understand why we should rush the
>major version up.
>  
>
I agree with this point even though I suggested August 1st. 7.5 has some 
extremely ambitious plans,
far greater than 7.3 or 7.4 implemented. A longer release cycle might be 
a good idea.

My personal daemons on this are:

Vacuum -- is the stuff Jan is working going to make a July 1st date? If 
not... 7.5 should push.
Win32 -- if it won't make it, then 7.5 should push.

PITR is nice but not as vital (IMHO) as the two above.

Replication -- we have either via Replicator or Slony-I which is due in 
a month.

Sincerely,

Joshua D. Drake





>--
>Tatsuo Ishii
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Don't 'kill -9' the postmaster
>  
>


-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL


Fri, 30 Apr 2004 18:16:30 -0700
"Joshua D. Drake" <jd@commandprompt.com>
Re: Plan for feature freeze?

Maybe we should take a vote on the cuttoff date scheduling.  Marc, is
this something that can be voted on by the group?

---------------------------------------------------------------------------

Tatsuo Ishii wrote:
> > > >>Why don't we just set a freeze of August 1st? Give everyone just a
> > > >>little extra time. No float. If it doesn't make
> > > >>it by August 1st, it doesn't make it.
> > > >>
> > > >>
> > > >
> > > >We could go for September 1st, which would mean most are back from
> > > >holidays, in order to do beta testing ... and no, I'm not serious ...
> > > >
> > > >
> > > >
> > > Why not? Seemed like a fairly good argument both yours and mine ;)
> > 
> > To me, it ranks up there with "lets freeze someday in the future" ...
> 
> For me even September 1st does not seem too late. Major version up
> bring users pains including backup/restore application
> imcompatibilty... IMO to justify those pains we need to give users
> major enhancements. Honestly I don't understand why we should rush the
> major version up.
> --
> Tatsuo Ishii
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

-- 
  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

Fri, 30 Apr 2004 21:22:54 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Plan for feature freeze?
On Fri, 30 Apr 2004, Bruce Momjian wrote:

>
> Maybe we should take a vote on the cuttoff date scheduling.  Marc, is
> this something that can be voted on by the group?

At this time, no ... in a months time, let's revisit it and see where the
various things are sitting ... quite frankly, we've spent more time on
this discussion that may even be warranted in a months time ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Fri, 30 Apr 2004 23:34:12 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: Plan for feature freeze?
On 30-Apr-04, at 8:53 PM, Tatsuo Ishii wrote:
> For me even September 1st does not seem too late. Major version up
> bring users pains including backup/restore application
> imcompatibilty... IMO to justify those pains we need to give users
> major enhancements. Honestly I don't understand why we should rush the
> major version up.

Yeah, I completely agree. I think a feature freeze date of August or 
September is definitely worth considering.

-Neil


Sat, 1 May 2004 01:46:40 -0400
Neil Conway <neilc@samurai.com>
Re: Plan for feature freeze?
> So you are floating the entire thing.  I am tired of discussing this.
> You call the freeze and when it is a disaster, you can take the credit.

People seem to _think_ that they can be ready by June 1st. To allow for 
unknown problems, why not set a freeze date at June 15?

By May 15 this date can be evaluated again. But at this point there should be 
stronger arguments to push the freeze date.

-- 
Kaare Rasmussen            --Linux, spil,--        Tlf:        3816 2582
Kaki Data                tshirts, merchandize      Fax:        3816 2501
Howitzvej 75               ï¿½ben 12.00-18.00        Email: kar@kakidata.dk
2000 Frederiksberg        Lï¿½rdag 12.00-16.00       Web:      www.suse.dk


Sat, 1 May 2004 10:27:44 +0200
Kaare Rasmussen <kar@kakidata.dk>
Re: Plan for feature freeze?
Neil Conway wrote:
> On 30-Apr-04, at 8:53 PM, Tatsuo Ishii wrote:
> > For me even September 1st does not seem too late. Major version up
> > bring users pains including backup/restore application
> > imcompatibilty... IMO to justify those pains we need to give users
> > major enhancements. Honestly I don't understand why we should rush the
> > major version up.
> 
> Yeah, I completely agree. I think a feature freeze date of August or 
> September is definitely worth considering.

Tatsuo brought up the an excellent point (that I have been saying for a
long time), that the number of must-fix bugs from previous releases is
shrinking, and the complexity of new features is increasing.

This dictates the that length of our release process should lengthen
over time.

-- 
  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

Sat, 1 May 2004 11:36:38 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Plan for feature freeze?


Bruce Momjian wrote:

>Neil Conway wrote:
>  
>
>>On 30-Apr-04, at 8:53 PM, Tatsuo Ishii wrote:
>>    
>>
>>>For me even September 1st does not seem too late. Major version up
>>>bring users pains including backup/restore application
>>>imcompatibilty... IMO to justify those pains we need to give users
>>>major enhancements. Honestly I don't understand why we should rush the
>>>major version up.
>>>      
>>>
>>Yeah, I completely agree. I think a feature freeze date of August or 
>>September is definitely worth considering.
>>    
>>
>
>Tatsuo brought up the an excellent point (that I have been saying for a
>long time), that the number of must-fix bugs from previous releases is
>shrinking, and the complexity of new features is increasing.
>
>This dictates the that length of our release process should lengthen
>over time.
>  
>


Last year feature freeze was declared in July, IIRC. That means that the 
release cycle is approaching a year. Even with major features I don't 
think that's too short. And there's every reason to think we will need 
some very intensive testing during the Beta period (Win32 and PITR for 
starters surely need some hard testing), so we could end up releasing 
around November, unless we're lucky.

In fact, the longer you make the release cycle the more people will get 
upset if they miss one.

I still think middle of June is about right for feature freeze (even 
though it's not my decision).

cheers

andrew


Sat, 01 May 2004 12:30:45 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: Plan for feature freeze?
Bruce Momjian wrote:
> Neil Conway wrote:
>>On 30-Apr-04, at 8:53 PM, Tatsuo Ishii wrote:
>>>For me even September 1st does not seem too late. Major version up
>>>bring users pains including backup/restore application
>>>imcompatibilty... IMO to justify those pains we need to give users
>>>major enhancements. Honestly I don't understand why we should rush the
>>>major version up.
>>
>>Yeah, I completely agree. I think a feature freeze date of August or 
>>September is definitely worth considering.
> 
> Tatsuo brought up the an excellent point (that I have been saying for a
> long time), that the number of must-fix bugs from previous releases is
> shrinking, and the complexity of new features is increasing.
> 
> This dictates the that length of our release process should lengthen
> over time.

I agree with this line of thought.

However, perhaps *some* of any increase in development time could be 
made up by changing how the beta period is handled. In the last two 
major releases (and possibly earlier ones also), beta lasted much longer 
than people seemed to think it would/should. Remember this thread from 
last summer:
   http://archives.postgresql.org/pgsql-advocacy/2003-07/msg00285.php
There was discussion regarding a release around September 1. When did we 
actually release? Mid-November.

So that made the 7.4 cycle about 7.5 months of development (2002-11-27 
to 2003-07-15 or thereabouts), and 4 months of beta (2003-07-15 to 
2003-11-17). I personally think our goal ought to be something like 9 to 
12 months of development, followed by 2 to 3 months of beta.

Joe

Sat, 01 May 2004 09:39:37 -0700
Joe Conway <mail@joeconway.com>
Re: Plan for feature freeze?
Joe Conway <mail@joeconway.com> writes:
> However, perhaps *some* of any increase in development time could be 
> made up by changing how the beta period is handled.

That would essentially amount to changing our criteria for "start of
beta".  How would you like to define it exactly?

We should also think about what exactly we mean by "feature freeze".
I've been using it as a shorthand for "we don't think we'll need any
more major code changes".  But depending on how high-level your notion
of "feature" is, it could be that fairly major code changes could still
be acceptable.  For instance if "feature" == "Win32 native port" then
all of the work still needed for the Win32 port might be argued to be
acceptable as post-feature-freeze work.  (I don't think this is actually
sensible, mind you, since it would be silly to stop other feature
development while Win32 still needs so much work.  My point is just that
we haven't defined "feature freeze" very well.)

In the past there has been little if any daylight between feature freeze
and start of beta --- in fact, IIRC we did not distinguish these
concepts at all until the last release or two.  It wouldn't be a bad
idea to try to nail down the terms of discussion a bit better.

			regards, tom lane

Sat, 01 May 2004 17:28:53 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Plan for feature freeze? 
Tom Lane wrote:
> We should also think about what exactly we mean by "feature freeze".
> I've been using it as a shorthand for "we don't think we'll need any
> more major code changes".  But depending on how high-level your notion
> of "feature" is, it could be that fairly major code changes could still
> be acceptable.  For instance if "feature" == "Win32 native port" then
> all of the work still needed for the Win32 port might be argued to be
> acceptable as post-feature-freeze work.  (I don't think this is actually
> sensible, mind you, since it would be silly to stop other feature
> development while Win32 still needs so much work.  My point is just that
> we haven't defined "feature freeze" very well.)
> 
> In the past there has been little if any daylight between feature freeze
> and start of beta --- in fact, IIRC we did not distinguish these
> concepts at all until the last release or two.  It wouldn't be a bad
> idea to try to nail down the terms of discussion a bit better.

As I remember, feature freeze means no new features, just fixes, and
beta means release of the first beta that we want for wide testing.

-- 
  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

Sat, 1 May 2004 17:39:47 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Plan for feature freeze?
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> We should also think about what exactly we mean by "feature freeze".

> As I remember, feature freeze means no new features, just fixes, and
> beta means release of the first beta that we want for wide testing.

I guess I wasn't clear: what I was asking for was some discussion about
the criteria we should use for advancing to each of those phases.  In
particular it's not real clear what "just fixes" should be interpreted
to allow for.  The remaining work for Win32 could all be called "just
fixes" since it will not add any user-visible "features".

			regards, tom lane

Sat, 01 May 2004 17:52:45 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Plan for feature freeze? 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> We should also think about what exactly we mean by "feature freeze".
> 
> > As I remember, feature freeze means no new features, just fixes, and
> > beta means release of the first beta that we want for wide testing.
> 
> I guess I wasn't clear: what I was asking for was some discussion about
> the criteria we should use for advancing to each of those phases.  In
> particular it's not real clear what "just fixes" should be interpreted
> to allow for.  The remaining work for Win32 could all be called "just
> fixes" since it will not add any user-visible "features".

I assume "just fixes" is for bugs not known when going into feature
freeze, meaning bugs found during testing.  If there are significant
missing parts going into feature freeze, I think you just abandon the
feature and rip it out or disable it.  We have done that in the past.

-- 
  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

Sat, 1 May 2004 17:54:45 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Plan for feature freeze?
On Sat, 1 May 2004, Tom Lane wrote:

> In the past there has been little if any daylight between feature freeze
> and start of beta --- in fact, IIRC we did not distinguish these
> concepts at all until the last release or two.  It wouldn't be a bad
> idea to try to nail down the terms of discussion a bit better.

Hrmmm ... what is the difference between freezing features and going into
beta?  Beta, to me, has always meant that we are now avoiding making any
changes to the code base that would add to any instabilities in the code
base ... we know there are probably bugs, but our focus is shifting from
adding to them to resolving them ... this is primarily a -hackers group
debugging and testing period.

Release Candidate broadens that to "we believe we've got all the bugs
worked out, but wish to see wider testing then we've been able to achieve
in Beta" ...

So, where does a 'feature freeze' figure in differently then a Beta?


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Sat, 1 May 2004 18:59:36 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Feature Freeze vs Beta (Was: Re: Plan for feature freeze?
 )
On Sat, 1 May 2004, Tom Lane wrote:

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> We should also think about what exactly we mean by "feature freeze".
>
> > As I remember, feature freeze means no new features, just fixes, and
> > beta means release of the first beta that we want for wide testing.
>
> I guess I wasn't clear: what I was asking for was some discussion about
> the criteria we should use for advancing to each of those phases.  In
> particular it's not real clear what "just fixes" should be interpreted
> to allow for.  The remaining work for Win32 could all be called "just
> fixes" since it will not add any user-visible "features".

I think its the scope (or maybe risk?) of the 'fixes' that tends to be the
deciding point ... for instannce, the sync/fsync work you've committed to
for the Win32 stuff, IMHO, is a very large "fix" that I'd not like to see
happen while in Beta ...



 ----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Sat, 1 May 2004 19:03:50 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: Plan for feature freeze? 
On Sat, 1 May 2004, Bruce Momjian wrote:

> I assume "just fixes" is for bugs not known when going into feature
> freeze, meaning bugs found during testing.

I don't agree with that ... I'd consider the Timezone stuff to be a
feature, since its major changes ... not having it working under Unix is a
major bug that needs to be fixed, but having it not working under, say,
Solaris but working everywhere else would be something that could be
addressed during Beta ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Sat, 1 May 2004 19:06:06 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Feature vs Beta Period (Was: Re: Plan for feature freeze?)
> Tatsuo brought up the an excellent point (that I have been saying for a
> long time), that the number of must-fix bugs from previous releases is
> shrinking, and the complexity of new features is increasing.
> 
> This dictates the that length of our release process should lengthen
> over time.

May I also make the point that I have only _just_ upgraded all our 
production database servers to 7.4?  Unless there are really compelling 
new features in 7.5, I as yet see no reason to upgrade to 7.5 at any point.

As Postgres gets larger and postgres databases get larger, and we 
properly maintain the previous versions, then the need to upgrade is 
gone.  It doesn't matter to me if it's a 1 year or 2 year development 
cycle at the moment.

Chris


Sun, 02 May 2004 13:11:15 +0800
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: Plan for feature freeze?