Re: Win32, PITR, nested transactions, tablespaces

On Fri, 28 May 2004, Bruce Momjian wrote:

> Marc G. Fournier wrote:
>> On Fri, 28 May 2004, Bruce Momjian wrote:
>>
>>> Tom Lane wrote:
>>>> "Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
>>>>> Off the top of my head ... the Installer and Service Manager come to mind
>>>>> ... and Tom's fsync changes ...
>>>>
>>>>> Right now, I'd say feature freeze is looking more like next Friday (June
>>>>> 4th), and we're evaluate it then ... that should hopefully give the above
>>>>> time to flesh out and get into CVS ...
>>>>
>>>> I intend to be done with fsync by Monday, but I won't have any time to
>>>> review these other patches until after that. So pushing feature freeze
>>>> back a week sounds like a good idea to me too. We need enough time to
>>>> make unhasty decisions about whether each of these features is ready
>>>> enough to go into 7.5 (or whatever we call it).
>>>
>>> Agreed, but I am concerned we are entering a period like we did with 7.3
>>> where we delay things a week at a time rather than in one-month chunks.
>>
>> The *only* thing we are pushing back the beta for is so that the Win32
>> stuff can be completed ...
>>
>> There is no reason why those working on the other features should be
>> slowing down as a result that they think they might not make it, since
>> even if they don't make it, it would be *really* nice to see the features
>> added at the start of the next dev cycle ...
>
> Reality check --- why should they keep going if the stuff if appication
> is going to be months away, and these big features are going to change
> CVS significanly anyway?
>
> Let's be honest --- if they aren't going to make it, they will stop
> working hard and do something else with their time.

'k, sounds reasonable ... so, since the feature freeze will most likely
happen next Friday (not guaranteed, of course), everyone working on
features that will not be done in time should just stop working on it ...
that should free up a bunch of ppl for testing those features that are
already in ...

Of course, that *is* based on the Reality Check you've so kindly provided
me ...

And, of course, that puts us into the next dev cycle with a bunch of half
finished, not ready to commit, features that will most likely be committed
days ahead of the feature freeze ... instead of a bunch of features that
were finished off *during* the beta cycle and ready to be committed the
day after we create the branch ...

Your Reality sounds like such a waste of time and talent, doesn't it?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664