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, Pennsylvania 19073Import Notes
Reply to msg id not found: 20040430155741.I45839@ganymede.hub.org
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, Pennsylvania 19073
Bruce Momjian said:
Marc G. Fournier wrote:
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.
ISTM the issue is "what freeze date is the sweet spot, that doen't hold us
up endlessly but allows maximum chance to get in some of the features we
badly need?"
My previous suggestion of mid June was based on my impressionistic
balancing those 2 factors.
Andrew Sullivan is right, though, about the bad press we would get from
missing shipping the Win32 port - it would do a lot of damage after it has
been talked up so much.
Andrew
Import Notes
Resolved by subject fallback
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 PostgreSQLOn 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
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 PostgreSQLOn 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 PostgreSQLMaybe 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 19073On 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, Pennsylvania 19073Bruce 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, Pennsylvania 19073Bruce 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, Pennsylvania 19073On 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