Thread: 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
containproprietary, 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,
pleasenotify the sender immediately by return e-mail, delete this communication and destroy all copies.
*************************************************************************
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 the > > > Oh, 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 the
>
>
> Oh, 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
containproprietary, 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,
pleasenotify the sender immediately by return e-mail, delete this communication and destroy all copies.
*************************************************************************
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 the > > > > > > Oh, 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/ > 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 the >> > >> > >> > Oh, 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 the > > > > > > Oh, 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, Pennsylvania19073
On 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, Pennsylvania19073
Bruce 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