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
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 SELECT
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
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
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 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
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 so much
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
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
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.
That
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 more
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
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 started out
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 more often.
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. Big
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
a
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
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
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, not
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 grain
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
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 have
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
they
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
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.
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
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.
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, 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
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 be that big
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
to have to
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
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, 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 though.
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
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
Marc G. Fournier wrote:
snip
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 ...
snip
Hmmm... so we do things slightly differently than previously...
This upcoming version could be PG version
37 matches
Mail list logo
