Official Freeze Date for 7.5: July 1st, 2004
Just so that everyone is aware, we are going to push the freeze date for
7.5 to July 1st.
Although we feel that there are enough improvements and features already
in place for 7.5, Tom's felt that if we gave it that extra month, we could
also have PITR in place for 7.5 ...
If anyone is working on other features that they feel can be polished off
before the July 1st deadline, we would be most happy to incorporate those
as well, but do recommend submitting patches for review *sooner*, rather
then later, so that any recommended corrections can be addressed before
teh deadline.
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Mon, 2004-05-31 at 19:09, Marc G. Fournier wrote:
Although we feel that there are enough improvements and features already
in place for 7.5, Tom's felt that if we gave it that extra month, we could
also have PITR in place for 7.5 ...
You have my full support and commitment for 1 July freeze.
...as-early-as-possible is understood...
Best Regards, Simon Riggs, 2nd Quadrant
Marc G. Fournier wrote:
If anyone is working on other features that they feel can be polished
off before the July 1st deadline, we would be most happy to incorporate
those as well, but do recommend submitting patches for review *sooner*,
rather then later, so that any recommended corrections can be addressed
before teh deadline.
I have a patch for delayed planning of unnamed statements when using the
extended query protocol that's in need of review:
http://archives.postgresql.org/pgsql-patches/2004-05/msg00348.php
-O
Oliver Jowett <oliver@opencloud.com> writes:
I have a patch for delayed planning of unnamed statements when using the
extended query protocol that's in need of review:
Right, I have it on my to-do list.
regards, tom lane
Marc G. Fournier wrote:
Just so that everyone is aware, we are going to push the freeze date
for 7.5 to July 1st.Although we feel that there are enough improvements and features
already in place for 7.5, Tom's felt that if we gave it that extra
month, we could also have PITR in place for 7.5 ...If anyone is working on other features that they feel can be polished
off before the July 1st deadline, we would be most happy to
incorporate those as well, but do recommend submitting patches for
review *sooner*, rather then later, so that any recommended
corrections can be addressed before teh deadline.
I welcome this, as I always thought June 1 was too soon. However, I
think that the process by which the date was eventually arrived at was
unfortunate.
I would modestly suggest that there should be a minimum period of notice
of a feature freeze - 6 weeks or 2 months seems about right to me, given
the development cycle we seem to have, and the fact that many of the
critical things people are working on are quite large.
(I'd also like to see someone who would get regular progress reports
from people who have undertaken to work on large/critical items, so that
we don't get into a position of thinking they will make a cutoff date
and then finding out late in the piece that they will not, but maybe
that's a discussion for another day).
cheers
andrew
Sounds like a project manager type should be put into place to organize
this information into a straight stream instead of 50 random mists of water
|---------+---------------------------------->
| | Andrew Dunstan |
| | <andrew@dunslane.net> |
| | Sent by: |
| | pgsql-hackers-owner@pos|
| | tgresql.org |
| | |
| | |
| | 06/01/2004 11:10 AM |
| | |
|---------+---------------------------------->
------------------------------------------------------------------------------------------------------------------------------|
| |
| To: pgsql-hackers@postgresql.org |
| cc: |
| Subject: Re: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004 |
------------------------------------------------------------------------------------------------------------------------------|
Marc G. Fournier wrote:
Just so that everyone is aware, we are going to push the freeze date
for 7.5 to July 1st.Although we feel that there are enough improvements and features
already in place for 7.5, Tom's felt that if we gave it that extra
month, we could also have PITR in place for 7.5 ...If anyone is working on other features that they feel can be polished
off before the July 1st deadline, we would be most happy to
incorporate those as well, but do recommend submitting patches for
review *sooner*, rather then later, so that any recommended
corrections can be addressed before teh deadline.
I welcome this, as I always thought June 1 was too soon. However, I
think that the process by which the date was eventually arrived at was
unfortunate.
I would modestly suggest that there should be a minimum period of notice
of a feature freeze - 6 weeks or 2 months seems about right to me, given
the development cycle we seem to have, and the fact that many of the
critical things people are working on are quite large.
(I'd also like to see someone who would get regular progress reports
from people who have undertaken to work on large/critical items, so that
we don't get into a position of thinking they will make a cutoff date
and then finding out late in the piece that they will not, but maybe
that's a discussion for another day).
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
*************************************************************************
PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
*************************************************************************
Import Notes
Resolved by subject fallback
On Tue, 1 Jun 2004, Andrew Dunstan wrote:
Marc G. Fournier wrote:
Just so that everyone is aware, we are going to push the freeze date for
7.5 to July 1st.Although we feel that there are enough improvements and features already
in place for 7.5, Tom's felt that if we gave it that extra month, we could
also have PITR in place for 7.5 ...If anyone is working on other features that they feel can be polished off
before the July 1st deadline, we would be most happy to incorporate those
as well, but do recommend submitting patches for review *sooner*, rather
then later, so that any recommended corrections can be addressed before
teh deadline.I welcome this, as I always thought June 1 was too soon. However, I think
that the process by which the date was eventually arrived at was unfortunate.I would modestly suggest that there should be a minimum period of notice of a
feature freeze - 6 weeks or 2 months seems about right to me, given the
Oh, you mean the original freeze date that was set at the start of the dev
cycle 6 months ago?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote:
On Tue, 1 Jun 2004, Andrew Dunstan wrote:
Marc G. Fournier wrote:
Just so that everyone is aware, we are going to push the freeze date
for 7.5 to July 1st.Although we feel that there are enough improvements and features
already in place for 7.5, Tom's felt that if we gave it that extra
month, we could also have PITR in place for 7.5 ...If anyone is working on other features that they feel can be
polished off before the July 1st deadline, we would be most happy to
incorporate those as well, but do recommend submitting patches for
review *sooner*, rather then later, so that any recommended
corrections can be addressed before teh deadline.I welcome this, as I always thought June 1 was too soon. However, I
think that the process by which the date was eventually arrived at
was unfortunate.I would modestly suggest that there should be a minimum period of
notice of a feature freeze - 6 weeks or 2 months seems about right to
me, given theOh, you mean the original freeze date that was set at the start of the
dev cycle 6 months ago?
I am far from being the only person to whom this was less than clear. I
also know that when I discussed this with one or two members of the core
team *they* were not clear about it either.
Maybe I missed something in an email somewhere ...
In any case, I think a target date should be set at the beginning of a
dev cycle and a hard date should be set closer to the end of the cycle.
Trying to adhere rigidly to a date set nine or twelve months previously
doesn't strike me as good practice.
cheers
andrew
I really hate seeing all the developers wasting time and brain cycles on
this type of stuff. I would much rather that time and brain cycles be put
to the design and development of the code.
Would a project manager type position be of any value to take some of this
off the developers and onto the project manager.? They would be the focal
point for this type of stuff and responsible to get updates from the
developers and check statuses and things of that nature.
|---------+---------------------------------->
| | Andrew Dunstan |
| | <andrew@dunslane.net> |
| | Sent by: |
| | pgsql-hackers-owner@pos|
| | tgresql.org |
| | |
| | |
| | 06/01/2004 12:26 PM |
| | |
|---------+---------------------------------->
------------------------------------------------------------------------------------------------------------------------------|
| |
| To: pgsql-hackers@postgresql.org |
| cc: |
| Subject: Re: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004 |
------------------------------------------------------------------------------------------------------------------------------|
Marc G. Fournier wrote:
On Tue, 1 Jun 2004, Andrew Dunstan wrote:
Marc G. Fournier wrote:
Just so that everyone is aware, we are going to push the freeze date
for 7.5 to July 1st.Although we feel that there are enough improvements and features
already in place for 7.5, Tom's felt that if we gave it that extra
month, we could also have PITR in place for 7.5 ...If anyone is working on other features that they feel can be
polished off before the July 1st deadline, we would be most happy to
incorporate those as well, but do recommend submitting patches for
review *sooner*, rather then later, so that any recommended
corrections can be addressed before teh deadline.I welcome this, as I always thought June 1 was too soon. However, I
think that the process by which the date was eventually arrived at
was unfortunate.I would modestly suggest that there should be a minimum period of
notice of a feature freeze - 6 weeks or 2 months seems about right to
me, given theOh, you mean the original freeze date that was set at the start of the
dev cycle 6 months ago?
I am far from being the only person to whom this was less than clear. I
also know that when I discussed this with one or two members of the core
team *they* were not clear about it either.
Maybe I missed something in an email somewhere ...
In any case, I think a target date should be set at the beginning of a
dev cycle and a hard date should be set closer to the end of the cycle.
Trying to adhere rigidly to a date set nine or twelve months previously
doesn't strike me as good practice.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
*************************************************************************
PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
*************************************************************************
Import Notes
Resolved by subject fallback
Having a good "hard copy" (not having to search mailing list archives)
of release dates would be really nice, not just for developers, but
users too. Even if they are subject to change without notice.
I think Mozilla has a great concept with there Milestone Schedule, the
gray table at: http://www.mozilla.org/roadmap.html#milestone-schedule.
I'm sure having just a small table like what Mozilla uses on the
PostgreSQL developers page would work wonders to eliminate much of the
confusion in the future.
On Tue, 2004-06-01 at 13:26 -0400, Andrew Dunstan wrote:
Marc G. Fournier wrote:
On Tue, 1 Jun 2004, Andrew Dunstan wrote:
Marc G. Fournier wrote:
Just so that everyone is aware, we are going to push the freeze date
for 7.5 to July 1st.Although we feel that there are enough improvements and features
already in place for 7.5, Tom's felt that if we gave it that extra
month, we could also have PITR in place for 7.5 ...If anyone is working on other features that they feel can be
polished off before the July 1st deadline, we would be most happy to
incorporate those as well, but do recommend submitting patches for
review *sooner*, rather then later, so that any recommended
corrections can be addressed before teh deadline.I welcome this, as I always thought June 1 was too soon. However, I
think that the process by which the date was eventually arrived at
was unfortunate.I would modestly suggest that there should be a minimum period of
notice of a feature freeze - 6 weeks or 2 months seems about right to
me, given theOh, you mean the original freeze date that was set at the start of the
dev cycle 6 months ago?I am far from being the only person to whom this was less than clear. I
also know that when I discussed this with one or two members of the core
team *they* were not clear about it either.Maybe I missed something in an email somewhere ...
In any case, I think a target date should be set at the beginning of a
dev cycle and a hard date should be set closer to the end of the cycle.
Trying to adhere rigidly to a date set nine or twelve months previously
doesn't strike me as good practice.cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
--
Mike Benoit <ipso@snappymail.ca>
Or even KDE as an example where they have both a document on the website
for release schedule and another one that is a list of features that are
desired for the next release, have been worked on, and have been
completed.
http://developer.kde.org/development-versions/
Show quoted text
Having a good "hard copy" (not having to search mailing list archives)
of release dates would be really nice, not just for developers, but
users too. Even if they are subject to change without notice.I think Mozilla has a great concept with there Milestone Schedule, the
gray table at: http://www.mozilla.org/roadmap.html#milestone-schedule.I'm sure having just a small table like what Mozilla uses on the
PostgreSQL developers page would work wonders to eliminate much of the
confusion in the future.On Tue, 2004-06-01 at 13:26 -0400, Andrew Dunstan wrote:
Marc G. Fournier wrote:
On Tue, 1 Jun 2004, Andrew Dunstan wrote:
Marc G. Fournier wrote:
Just so that everyone is aware, we are going to push the freeze date
for 7.5 to July 1st.Although we feel that there are enough improvements and features
already in place for 7.5, Tom's felt that if we gave it that extra
month, we could also have PITR in place for 7.5 ...If anyone is working on other features that they feel can be
polished off before the July 1st deadline, we would be most happy to
incorporate those as well, but do recommend submitting patches for
review *sooner*, rather then later, so that any recommended
corrections can be addressed before teh deadline.I welcome this, as I always thought June 1 was too soon. However, I
think that the process by which the date was eventually arrived at
was unfortunate.I would modestly suggest that there should be a minimum period of
notice of a feature freeze - 6 weeks or 2 months seems about right to
me, given theOh, you mean the original freeze date that was set at the start of the
dev cycle 6 months ago?I am far from being the only person to whom this was less than clear. I
also know that when I discussed this with one or two members of the core
team *they* were not clear about it either.Maybe I missed something in an email somewhere ...
In any case, I think a target date should be set at the beginning of a
dev cycle and a hard date should be set closer to the end of the cycle.
Trying to adhere rigidly to a date set nine or twelve months previously
doesn't strike me as good practice.cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org--
Mike Benoit <ipso@snappymail.ca>---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
On Tue, 2004-06-01 at 18:26, Andrew Dunstan wrote:
Marc G. Fournier wrote:
On Tue, 1 Jun 2004, Andrew Dunstan wrote:
Marc G. Fournier wrote:
Just so that everyone is aware, we are going to push the freeze date
for 7.5 to July 1st.Although we feel that there are enough improvements and features
already in place for 7.5, Tom's felt that if we gave it that extra
month, we could also have PITR in place for 7.5 ...If anyone is working on other features that they feel can be
polished off before the July 1st deadline, we would be most happy to
incorporate those as well, but do recommend submitting patches for
review *sooner*, rather then later, so that any recommended
corrections can be addressed before teh deadline.I welcome this, as I always thought June 1 was too soon. However, I
think that the process by which the date was eventually arrived at
was unfortunate.I would modestly suggest that there should be a minimum period of
notice of a feature freeze - 6 weeks or 2 months seems about right to
me, given theOh, you mean the original freeze date that was set at the start of the
dev cycle 6 months ago?I am far from being the only person to whom this was less than clear. I
also know that when I discussed this with one or two members of the core
team *they* were not clear about it either.Maybe I missed something in an email somewhere ...
The June 1st date was first mentioned on list in mid-March (to me), but
wasn't generally announced until May under a specific heading. If it was
set in January, I was never knowingly party to that info.
Major-architectural changes notwithstanding, xlog archiving was
originally completed in late April, having started in Feb.
A published schedule might have helped all of us to understand the
impact of an extra weeks discussion etc..
Personally, I feel I had good notice, but that doesn't mean it was
possible for me to finish by that time...
Best Regards, Simon Riggs
On Tuesday 01 June 2004 16:08, Simon Riggs wrote:
The June 1st date was first mentioned on list in mid-March (to me), but
wasn't generally announced until May under a specific heading. If it was
set in January, I was never knowingly party to that info.
Well, it should not have surprised anyone. We have targeted June 1 as a beta
freeze date for several versions, not just 7.5. In fact, looking back
through last year's pre-7.4 discussion, it's deja vu all over again....
Please read the thread "Release cycle
length" ( http://archives.postgresql.org/pgsql-hackers/2003-11/msg00889.php )
and follow it through. We're following the same track we did with 7.4. Are
we going to be a full year this time? (4.5 months from freeze to release
last time....)
But I could not find using the archives the date June 1 (except in relation to
the 7.4 freeze for 6/1/2003).
The closest to such a discussion would have been in the thread
http://archives.postgresql.org/pgsql-hackers/2004-01/msg00273.php, at least
that's all I could find.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
Lamar Owen wrote:
On Tuesday 01 June 2004 16:08, Simon Riggs wrote:
The June 1st date was first mentioned on list in mid-March (to me), but
wasn't generally announced until May under a specific heading. If it was
set in January, I was never knowingly party to that info.Well, it should not have surprised anyone. We have targeted June 1 as a beta
freeze date for several versions, not just 7.5. In fact, looking back
through last year's pre-7.4 discussion, it's deja vu all over again....
Here's what Tom said on 31 March:
----------
"Simon Riggs" <simon@2ndquadrant.com> writes:
[ expecting to finish PITR by early June ]
Is this all still OK for 7.5? (My attempts at cataloguing changes has
fallen by the wayside in concentrating on the more important task of
PITR.) Do we have a planned freeze month yet?
There's not really a plan at the moment, but I had June in the back of
my head as a good time; it looks to me like the Windows port will be
stable enough for beta in another month or two, and it'd be good if
PITR were ready to go by then.
----------------------
That seems to indicate that at that stage, barely 2 months ago, the
month was not definite, let alone the day.
I confess that as a newcomer I was not around before the 7.4 cycle, so
saying that people should have known the freeze date because it is
following past patterns doesn't help me much. Are people supposed to
obtain this info by trawling mailing list archives years back, or by
some sort of divine revelation? Other OS projects manage this whole
process better, IMNSHO. I'm not trying to point fingers, but to get
future improvement.
cheers
andrew
Andrew Dunstan wrote:
That seems to indicate that at that stage, barely 2 months ago, the
month was not definite, let alone the day.I confess that as a newcomer I was not around before the 7.4 cycle, so
saying that people should have known the freeze date because it is
following past patterns doesn't help me much. Are people supposed to
obtain this info by trawling mailing list archives years back, or by
some sort of divine revelation? Other OS projects manage this whole
process better, IMNSHO. I'm not trying to point fingers, but to get
future improvement.
I sent this email on April 16th asking for a status on the big 7.5
features:
---------------------------------------------------------------------------
On Tuesday 01 June 2004 22:15, Andrew Dunstan wrote:
Lamar Owen wrote:
Well, it should not have surprised anyone. We have targeted June 1 as a
beta freeze date for several versions, not just 7.5. In fact, looking
back through last year's pre-7.4 discussion, it's deja vu all over
again....I confess that as a newcomer I was not around before the 7.4 cycle, so
saying that people should have known the freeze date because it is
following past patterns doesn't help me much. Are people supposed to
obtain this info by trawling mailing list archives years back, or by
some sort of divine revelation? Other OS projects manage this whole
process better, IMNSHO. I'm not trying to point fingers, but to get
future improvement.
There is a reason I wrote the message a long time ago (that, I think, is still
in the Developer's FAQ) about how to get started in PostgreSQL development.
The first thing a developer should do before getting too involved in the
process is to get a feel for the development culture. The PostgreSQL
development is not like other open source projects, and does depend to some
extent on tradition and precedent. So skimming through the archives and
following [HACKERS] for six months is really required before getting
seriously involved in the process. You need to see how the process really is
handled, and to see how the 'Release Manager' and 'Patch-o-matic' get in gear
late in the cycle. The pieces really do fit together, we really do have
somewhat of a project management structure, but we are really laid-back in
our approach. This is the culture of this project, and I for one don't think
it should change. It certainly has worked this far.
One doesn't just start writing code for a project this size.
Having said that, I don't know very many who have actually followed that
advice.... :-)
But following through a cycle or two in the archives provides ample evidence
for the 'laid-back' model used here. It's ready when it's ready. We try to
schedule, but the schedules are pretty flexible.
And while most discussion happens here on [HACKERS], not all of it does. Some
happens on IRC, some in [CORE], and some by telephone. And it's been that
way for a while.
PostgreSQL is not a 'release early, release often' project. And that's OK.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
Lamar Owen wrote:
On Tuesday 01 June 2004 22:15, Andrew Dunstan wrote:
Lamar Owen wrote:
Well, it should not have surprised anyone. We have targeted June 1 as a
beta freeze date for several versions, not just 7.5. In fact, looking
back through last year's pre-7.4 discussion, it's deja vu all over
again....I confess that as a newcomer I was not around before the 7.4 cycle, so
saying that people should have known the freeze date because it is
following past patterns doesn't help me much. Are people supposed to
obtain this info by trawling mailing list archives years back, or by
some sort of divine revelation? Other OS projects manage this whole
process better, IMNSHO. I'm not trying to point fingers, but to get
future improvement.There is a reason I wrote the message a long time ago (that, I think, is still
in the Developer's FAQ) about how to get started in PostgreSQL development.
The first thing a developer should do before getting too involved in the
process is to get a feel for the development culture. The PostgreSQL
development is not like other open source projects, and does depend to some
extent on tradition and precedent. So skimming through the archives and
following [HACKERS] for six months is really required before getting
seriously involved in the process. You need to see how the process really is
handled, and to see how the 'Release Manager' and 'Patch-o-matic' get in gear
late in the cycle. The pieces really do fit together, we really do have
somewhat of a project management structure, but we are really laid-back in
our approach. This is the culture of this project, and I for one don't think
it should change. It certainly has worked this far.One doesn't just start writing code for a project this size.
Having said that, I don't know very many who have actually followed that
advice.... :-)But following through a cycle or two in the archives provides ample evidence
for the 'laid-back' model used here. It's ready when it's ready. We try to
schedule, but the schedules are pretty flexible.And while most discussion happens here on [HACKERS], not all of it does. Some
happens on IRC, some in [CORE], and some by telephone. And it's been that
way for a while.PostgreSQL is not a 'release early, release often' project. And that's OK.
If it were true that June 1 was the expected Beta data, then perhaps
that should be in the FAQ too, as a counterweight to the gratuitously
patronising advice which, had I followed it, might have resulted in my
not making a number of contributions.
But it is not true. I have already pointed out what Tom said on March
31: " There's not really a plan at the moment, but I had June in the
back of my head as a good time". IOW, June was a possible month,
nothing was settled, certainly not a definite day. So ISTM your premise
is simply wrong.
All I have asked for is a) reasonable clarity and b) reasonable notice.
I do not see that either of those conflict with being laid-back or
anything else above.
cheers
andrew
Andrew Dunstan wrote:
But following through a cycle or two in the archives provides ample evidence
for the 'laid-back' model used here. It's ready when it's ready. We try to
schedule, but the schedules are pretty flexible.And while most discussion happens here on [HACKERS], not all of it does. Some
happens on IRC, some in [CORE], and some by telephone. And it's been that
way for a while.PostgreSQL is not a 'release early, release often' project. And that's OK.
If it were true that June 1 was the expected Beta data, then perhaps
that should be in the FAQ too, as a counterweight to the gratuitously
patronising advice which, had I followed it, might have resulted in my
not making a number of contributions.But it is not true. I have already pointed out what Tom said on March
31: " There's not really a plan at the moment, but I had June in the
back of my head as a good time". IOW, June was a possible month,
nothing was settled, certainly not a definite day. So ISTM your premise
is simply wrong.All I have asked for is a) reasonable clarity and b) reasonable notice.
I do not see that either of those conflict with being laid-back or
anything else above.
I believe the decision for June 1 was made around May 1. I participated
in the discussion. Should we have made that final decision sooner?
--
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, 5 Jun 2004, Andrew Dunstan wrote:
All I have asked for is a) reasonable clarity and b) reasonable notice.
I do not see that either of those conflict with being laid-back or
anything else above.
Something we definitely will work on, in both cases ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Bruce Momjian wrote:
I believe the decision for June 1 was made around May 1. I participated
in the discussion. Should we have made that final decision sooner?
No, I think that was the right time to make a decision. Before that
things were in a great state of flux. My suggestion is that there should
be some minimum time (I suggested 6 weeks to 2 months) between when the
decision is made/announced and the actual freeze date. In the present
case we would have probably have ended up with a date very like what we
now have, but without the June 1 false start, which many (including me)
felt tried to set the date too early and gave insufficient notice to
those who wanted to make the cut.
cheers
andrew
On Sat, 5 Jun 2004, Andrew Dunstan wrote:
No, I think that was the right time to make a decision. Before that
things were in a great state of flux. My suggestion is that there should
be some minimum time (I suggested 6 weeks to 2 months) between when the
decision is made/announced and the actual freeze date. In the present
case we would have probably have ended up with a date very like what we
now have, but without the June 1 false start, which many (including me)
felt tried to set the date too early and gave insufficient notice to
those who wanted to make the cut.
Except, as some have already mentioned, the June 1st "false start" as you
put it, was never a surprise ... *shrug*
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote:
On Sat, 5 Jun 2004, Andrew Dunstan wrote:
No, I think that was the right time to make a decision. Before that
things were in a great state of flux. My suggestion is that there
should be some minimum time (I suggested 6 weeks to 2 months) between
when the decision is made/announced and the actual freeze date. In
the present case we would have probably have ended up with a date
very like what we now have, but without the June 1 false start, which
many (including me) felt tried to set the date too early and gave
insufficient notice to those who wanted to make the cut.Except, as some have already mentioned, the June 1st "false start" as
you put it, was never a surprise ... *shrug*
We've been aropund this block already, so I'm not going to continue. If
you think the process is working just fine then don't change it. I
don't, but then I am not in a position to make the decisions.
cheers
andrew
On Sat, 5 Jun 2004, Andrew Dunstan wrote:
Marc G. Fournier wrote:
On Sat, 5 Jun 2004, Andrew Dunstan wrote:
No, I think that was the right time to make a decision. Before that
things were in a great state of flux. My suggestion is that there should
be some minimum time (I suggested 6 weeks to 2 months) between when the
decision is made/announced and the actual freeze date. In the present
case we would have probably have ended up with a date very like what we
now have, but without the June 1 false start, which many (including me)
felt tried to set the date too early and gave insufficient notice to
those who wanted to make the cut.Except, as some have already mentioned, the June 1st "false start" as you
put it, was never a surprise ... *shrug*We've been aropund this block already, so I'm not going to continue. If you
think the process is working just fine then don't change it. I don't, but
then I am not in a position to make the decisions.
Note that I do agree with several of the suggestions and points that have
been made concerning this ... I also agree that the knowledge was not
known by everyone ... the point is/was that some were working to the June
1st freeze ... for next release, we need to make sure that everyone is
working to the same freeze ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Saturday 05 June 2004 10:13, Andrew Dunstan wrote:
Lamar Owen wrote:
There is a reason I wrote the message a long time ago (that, I think, is
still in the Developer's FAQ) about how to get started in PostgreSQL
development. The first thing a developer should do before getting too
involved in the process is to get a feel for the development culture.
If it were true that June 1 was the expected Beta data, then perhaps
that should be in the FAQ too, as a counterweight to the gratuitously
patronising advice which, had I followed it, might have resulted in my
not making a number of contributions.
I'm sorry you consider the advice to be 'patronizing' : I can assure you it is
not meant that way. It was written from the point of view of someone who had
been around the block and had seen how things work (and in my case one who
did not do it that way, and regrets it). And I don't think I ever
recommended not coding while just reading mailing lists; rather, it should be
a hand in hand process: you learn the code while you learn the community.
All I have asked for is a) reasonable clarity and b) reasonable notice.
I do not see that either of those conflict with being laid-back or
anything else above.
As Marc said, that is certainly something that could use work, since we have
never really been clear in dates: primarily because we never have met them.
Please lighten up, that's all. That's one thing I have found helps in this
project, and maybe it's not something I made clear, but we are 'laid back'
including a fair amount of humor. A good portion of that goes on privately;
I remember ribbing Bruce a couple of cycles back with some Biblical
references about the signs of the times (he was in 'let's go back through the
mailing list a few weeks and pick up TODO items and patches' mode, and I
commented that it must be time for beta, due to the signs of the times.).
The lesson of the history of our beta 'freezes' is that the permafrost tends
to be thin early in the beta cycle, and gets progressively thicker as the
cycle progresses. And we have never met the early dates, as evidenced by
Peter Eisentraut's desire to see us freeze in March (which obviously did not
happen).
And my advice is to simply get some context about the process. One gets
context of the code; one should apply the same effort to getting the context
of the process. With PostgreSQL the code is large and it takes considerable
digging to really get into contributing mode; it takes similar amounts of
digging to merge into the process. Is this a wrong thing to do?
And your contributions are very appreciated, by me in particular. Fresh code
ideas, properly applied, are always welcome.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
Lamar Owen wrote:
Please lighten up, that's all. That's one thing I have found helps in this
project, and maybe it's not something I made clear, but we are 'laid back'
including a fair amount of humor. A good portion of that goes on privately;
I remember ribbing Bruce a couple of cycles back with some Biblical
references about the signs of the times (he was in 'let's go back through the
mailing list a few weeks and pick up TODO items and patches' mode, and I
commented that it must be time for beta, due to the signs of the times.).
Old habits die hard - all my life I've pushed for things I care about.
Still, I hope I retain a sense of humor - the other day someone asked me
about the freeze date, and I said I believed that the day and month had
been settled on but people were still arguing about the year ;-)
cheers
andrew
Andrew Dunstan wrote:
Bruce Momjian wrote:
I believe the decision for June 1 was made around May 1. I participated
in the discussion. Should we have made that final decision sooner?No, I think that was the right time to make a decision. Before that
things were in a great state of flux. My suggestion is that there should
be some minimum time (I suggested 6 weeks to 2 months) between when the
decision is made/announced and the actual freeze date. In the present
case we would have probably have ended up with a date very like what we
now have, but without the June 1 false start, which many (including me)
felt tried to set the date too early and gave insufficient notice to
those who wanted to make the cut.
I understand. You are saying that we couldn't set the date until May 1,
but on May 1 we should have set the date farther way, like 6-8 weeks,
rather than 4.5 weeks, right?
On that, I certainly agree.
--
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:
I understand. You are saying that we couldn't set the date until May 1,
but on May 1 we should have set the date farther way, like 6-8 weeks,
rather than 4.5 weeks, right?
I think there are a couple of important points in this discussion.
One is that the beta freeze date is inherently fuzzy, and only gets
solid as we get close to it. It would not have helped any for us
to announce "June 1 is the freeze date" in January; back then it was
just too hard to tell what might get done by June 1. By March it was
possible for me to say "I'm thinking about June" but it was still not
exactly a hard target. We tried to set a hard target around the
beginning of May ... well, it turned out to be the wrong hard target,
so maybe that was still too far away.
The other point is that core could be doing a better job of
communicating our ideas about schedule. On this I agree.
As long as you realize that the process is inherently fuzzy...
but we could certainly have been noisier in March about saying
that we were thinking of a June-ish freeze, and so forth.
regards, tom lane