Thread: Re: Plan for feature freeze?
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, Pennsylvania19073
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
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, Pennsylvania19073
Hello,<br /><br /> Why don't we just set a freeze of August 1st? Give everyone just a little extra time. No float. If itdoesn't make<br /> it by August 1st, it doesn't make it.<br /><br /> This could also lead to other things. For exampleif we have Win32 and PITR calling it 7.5 is a mistake (IMHO) it should<br /> be 8.0 etc...<br /><br /> Sincerely,<br/><br /> Joshua D. Drake<br /><br /><br /> Sincerely,<br /><br /> Joshua D. Drake<br /><br /><br /> Bruce Momjianwrote: <blockquote cite="mid200404302057.i3UKvnW17466@candle.pha.pa.us" type="cite"><pre wrap="">Marc G. Fournierwrote: </pre><blockquote type="cite"><pre wrap="">On Fri, 30 Apr 2004, Bruce Momjian wrote: </pre><blockquote type="cite"><pre wrap="">Marc G. Fournier wrote: </pre><blockquote type="cite"><blockquote type="cite"><blockquotetype="cite"><pre wrap="">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 ... </pre></blockquote><pre wrap="">OK, what is the plan for featurefreeze? 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? </pre></blockquote><pre wrap="">1 of the major features thatare 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 ... </pre></blockquote><pre wrap="">OK, butI 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. </pre></blockquote><pre wrap="">No no ... the dateisn'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 ... </pre></blockquote><pre wrap=""> 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. </pre></blockquote><br /><br /><pre class="moz-signature" cols="72">-- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - <a class="moz-txt-link-abbreviated" href="mailto:jd@commandprompt.com">jd@commandprompt.com</a> - <a class="moz-txt-link-freetext"href="http://www.commandprompt.com">http://www.commandprompt.com</a> PostgreSQL Replicator -- production quality replication for PostgreSQL</pre>
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
<br /><blockquote cite="mid20040430202625.Q45839@ganymede.hub.org" type="cite"><blockquote type="cite"><pre wrap=""> 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. </pre></blockquote><pre wrap=""> 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 ... </pre></blockquote> Why not? Seemed like a fairly good argument both yours and mine ;)<br /><br /> Sincerely,<br /><br />Joshua D. Drake<br /><br /><br /><br /><blockquote cite="mid20040430202625.Q45839@ganymede.hub.org" type="cite"><pre wrap=""> ---- Marc G. Fournier Hub.Org Networking Services (<a class="moz-txt-link-freetext" href="http://www.hub.org">http://www.hub.org</a>) Email: <a class="moz-txt-link-abbreviated" href="mailto:scrappy@hub.org">scrappy@hub.org</a> Yahoo!: yscrappy ICQ: 7615664 </pre></blockquote><br /><br /><pre class="moz-signature" cols="72">-- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - <a class="moz-txt-link-abbreviated" href="mailto:jd@commandprompt.com">jd@commandprompt.com</a> - <a class="moz-txt-link-freetext"href="http://www.commandprompt.com">http://www.commandprompt.com</a> PostgreSQL Replicator -- production quality replication for PostgreSQL</pre>
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
> > >>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
>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
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, Pennsylvania19073
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
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
> 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
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, Pennsylvania19073
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
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
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
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, Pennsylvania19073
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
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, Pennsylvania19073
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
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
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
> 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