Re: Official Freeze Date for 7.5: July 1st, 2004

From: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
To: "Mike Benoit" <ipso(at)snappymail(dot)ca>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Official Freeze Date for 7.5: July 1st, 2004
Date: 2004-06-01 19:30:08
Message-ID: 51957.192.154.91.225.1086118208.squirrel@192.154.91.225
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)postgresql(dot)org
> --
> Mike Benoit <ipso(at)snappymail(dot)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
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2004-06-01 19:53:50 Re: Win32, PITR, nested transactions, tablespaces
Previous Message Tom Lane 2004-06-01 19:21:25 Re: Fast index build vs. PITR