Christopher Kings-Lynne wrote:
> > We can have a major feature deadline, then a minor feature deadline. I
> > particularly liked the idea of 1 July as the major feature deadline,
> > then 14 July as major-feature-tweak deadline. That funnels things better
> > to cater for the manpower available.
>
On Thu, 15 Jul 2004, Christopher Kings-Lynne wrote:
We can have a major feature deadline, then a minor feature deadline. I
particularly liked the idea of 1 July as the major feature deadline,
then 14 July as major-feature-tweak deadline. That funnels things better
to cater for the manpower availabl
We can have a major feature deadline, then a minor feature deadline. I
particularly liked the idea of 1 July as the major feature deadline,
then 14 July as major-feature-tweak deadline. That funnels things better
to cater for the manpower available.
That being said, your PITR patch still hasn't bee
On Wed, 2004-07-14 at 21:02, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > The big problem that I see with how this feature freeze/beta/release has
> > gone down is that we have *alot* of big items that are/were being worked
> > on (ARC, BGWriter, auto_vacuum, PITR, Nested Xacts), and only s
On Tue, 2004-07-13 at 23:03, Marc G. Fournier wrote:
> As a community, I don't think we should be 'supporting' anything older
> then the last STABLE ...
>
I agree, but that message isn't clearly stated anywhere. The lists are
full of people running very old releases - and everybody keeps having
Marc G. Fournier wrote:
> The big problem that I see with how this feature freeze/beta/release has
> gone down is that we have *alot* of big items that are/were being worked
> on (ARC, BGWriter, auto_vacuum, PITR, Nested Xacts), and only so much man
> power at the reviewer stage ... we *should*
On 7/14/2004 1:13 PM, Bruce Momjian wrote:
What are you talking about? Are you suggesting Fujitsu's features are
getting more attendtion than ARC for some political reason? You think
nested transactions and tablespaces are just press release features?
All those features are being developed by th
On Wed, 14 Jul 2004, Bruce Momjian wrote:
What are you talking about? Are you suggesting Fujitsu's features are
getting more attendtion than ARC for some political reason? You think
nested transactions and tablespaces are just press release features?
All those features are being developed by the
Jan Wieck wrote:
> On 7/13/2004 10:23 PM, Christopher Kings-Lynne wrote:
>
> >> I was thinking of something much simpler where Jan would create an ARC
> >> patch against 7.4.X and have it either in /contrib for 7.4.X or on our
> >> ftp servers, or on a web site. I could create a mechanism so SELE
On 7/13/2004 10:23 PM, Christopher Kings-Lynne wrote:
I was thinking of something much simpler where Jan would create an ARC
patch against 7.4.X and have it either in /contrib for 7.4.X or on our
ftp servers, or on a web site. I could create a mechanism so SELECT
version() would display Jan's add-
Marc G. Fournier wrote:
As Jan points out, its the 'small features that are done' that we've
been griping about having to wait for, not the big ones which we know
aren't done ...
Hmmm... so we do things slightly differently than previously...
This upcoming version could be PG version 8.0,
We co
I was thinking of something much simpler where Jan would create an ARC
patch against 7.4.X and have it either in /contrib for 7.4.X or on our
ftp servers, or on a web site. I could create a mechanism so SELECT
version() would display Jan's add-on.
I think you guys just need to learn to become comf
God, we still have clients using 7.2 servers, cause they've had no
reason yet to upgrade to the latest ... "it works, why upgrade?" is
generally the opinion ...
Because there's shocking failure-to-restart bugs in 7.2...and if you
upgrade to 7.4 you're forced to get new features as well.
Chris
-
On Tue, 2004-07-13 at 20:49, Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Tom Lane wrote:
>
> > We could certainly do something along that line if we had a few people
> > willing to be "gatekeepers". We'd have to work harder at making the
> > release generation process open and documented tho
> However, looking at how the Linux community handles it, I think we can
> borrow a lot of concepts from them.
I was thinking quite the opposite. The Linux community doesn't exactly
have a great track-record for their stable releases.
The thoughts behind the process might be good, but do we have
On Tue, 13 Jul 2004, Bruce Momjian wrote:
The nice thing about doing something lke that is those small features
would get a degree of testing happening in a live environment ...
Of course that last sentence is the downside too --- people don't want
to have to retest their setups after a minor relea
Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Bruce Momjian wrote:
>
> >> The nice thing about doing something lke that is those small features
> >> would get a degree of testing happening in a live environment ...
> >
> > Of course that last sentence is the downside too --- people don't want
> >
On Tue, 2004-07-13 at 13:03 -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Jan Wieck wrote:
> >> I think in the future we have to force all large features, those that
> >> probably need more than 6 months of development time, to be properly
> >> #ifdef'd. Then it wouldn't
On Tue, 13 Jul 2004, Bruce Momjian wrote:
We have always recommended upgrading to the most recent minor release,
at least as a project policy for support. Also, the upgrade is only
stop/install/restart so it is quite easy to do, and folks like the fact
they don't have to test for new functional
Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Bruce Momjian wrote:
>
> > I was thinking of something much simpler where Jan would create an ARC
> > patch against 7.4.X and have it either in /contrib for 7.4.X or on our
> > ftp servers, or on a web site. I could create a mechanism so SELECT
>
On Tue, 13 Jul 2004, Lamar Owen wrote:
But Tom's assertion is true. We have enough trouble getting patches
rolled out; adding parallel branches is just begging for trouble, due to
our relatively small resource size. Although, we probably have enough
developers at this point to make it happen.
On Tue, 13 Jul 2004, Bruce Momjian wrote:
I was thinking of something much simpler where Jan would create an ARC
patch against 7.4.X and have it either in /contrib for 7.4.X or on our
ftp servers, or on a web site. I could create a mechanism so SELECT
version() would display Jan's add-on.
I thi
On Wed, 14 Jul 2004, Peter Eisentraut wrote:
Marc G. Fournier wrote:
Nobody would be required to upgrade to a new minor release either ...
nobody is *require* to upgrade to any release, for that matter ...
Most people don't have the time to investigate release notes, release
policy details, etc. W
On Tue, 13 Jul 2004, Tom Lane wrote:
We could certainly do something along that line if we had a few people
willing to be "gatekeepers". We'd have to work harder at making the
release generation process open and documented though. Right now there
are plenty of steps that only you, Bruce, or La
Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Bruce Momjian wrote:
>
> > We have always recommended upgrading to the most recent minor release,
> > at least as a project policy for support. Also, the upgrade is only
> > stop/install/restart so it is quite easy to do, and folks like the fact
>
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Tue, 13 Jul 2004, Lamar Owen wrote:
>> But Tom's assertion is true. We have enough trouble getting patches
>> rolled out; adding parallel branches is just begging for trouble, due to
>> our relatively small resource size. Although, we probably
Marc G. Fournier wrote:
> Nobody would be required to upgrade to a new minor release either ...
> nobody is *require* to upgrade to any release, for that matter ...
Most people don't have the time to investigate release notes, release
policy details, etc. When there are bug fix updates, you use
On Tuesday 13 July 2004 08:52 am, Jan Wieck wrote:
>
> I think in the future we have to force all large features, those that
> probably need more than 6 months of development time, to be properly
> #ifdef'd. Then it wouldn't be that big of a deal to release more often.
>
>
Take my opinion with a g
On Tuesday 13 July 2004 17:12, Marc G. Fournier wrote:
> ... there is alot of stuff that doesn't require a reload of the database
> (or initdb) that could very easily be backpatched ...
> As Jan points out, its the 'small features that are done' that we've been
> griping about having to wait for,
Marc G. Fournier wrote:
>
> Note that I'm all for a long (2 year? or even 'indefinite') development
> cycle for a major release if we continue on with what has been happening
> more often lately, where stuff is back patched to the last stable release
> ... there is alot of stuff that doesn't re
Note that I'm all for a long (2 year? or even 'indefinite') development
cycle for a major release if we continue on with what has been happening
more often lately, where stuff is back patched to the last stable release
... there is alot of stuff that doesn't require a reload of the database
(or
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Of course this all ties into the pain of having to dump/reload large
> >> databases, and maybe if we had working pg_upgrade the adoption rate
> >> would be faster, but I'm not at all sure of that. We're playing in
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Of course this all ties into the pain of having to dump/reload large
>> databases, and maybe if we had working pg_upgrade the adoption rate
>> would be faster, but I'm not at all sure of that. We're playing in
>> a different league now
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Jan Wieck wrote:
> >> I think in the future we have to force all large features, those that
> >> probably need more than 6 months of development time, to be properly
> >> #ifdef'd. Then it wouldn't be that big of a deal to release mo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Jan Wieck wrote:
>> I think in the future we have to force all large features, those that
>> probably need more than 6 months of development time, to be properly
>> #ifdef'd. Then it wouldn't be that big of a deal to release more often.
> Alvaro starte
On 7/10/2004 11:02 PM, Bruce Momjian wrote:
If you get full control of PostgreSQL, you can dictate what will happen.
Until then, I will follow the community consensus, which may or may not
match your opinion.
Marc isn't the only one who didn't like waiting for more features going
into 7.5 two mont
Jan Wieck wrote:
> On 7/10/2004 11:02 PM, Bruce Momjian wrote:
>
> > If you get full control of PostgreSQL, you can dictate what will happen.
> > Until then, I will follow the community consensus, which may or may not
> > match your opinion.
>
> Marc isn't the only one who didn't like waiting for
37 matches
Mail list logo
