Re: Official Freeze Date for 7.5: July 1st, 2004 - Mailing list pgsql-hackers
From | Matthew T. O'Connor |
---|---|
Subject | Re: Official Freeze Date for 7.5: July 1st, 2004 |
Date | |
Msg-id | 51957.192.154.91.225.1086118208.squirrel@192.154.91.225 Whole thread Raw |
In response to | Re: Official Freeze Date for 7.5: July 1st, 2004 (Mike Benoit <ipso@snappymail.ca>) |
List | pgsql-hackers |
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 > >
pgsql-hackers by date: