Dave Page wrote:
Stefan Kaltenbrunner wrote:
This means that there is a huge rush of new code in pgAdmin's
development cycle, right at the time when we should be testing - making
the release process more and more rushed as each release of PostgreSQL
gets more efficient and adds more and more
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
I like the idea of having a sync point mid cycle, however, what I'd like
to see even more is an improved system in which we put less pressure on
the few committers we have, and give them more freedom to commit patches
they may not
Stefan Kaltenbrunner wrote:
Interesting ... so if you have a new feature (or a number of them) -
that is not directly depending on some sort of new backend feature - in
pgadmin you delay it until the next postgresql mjor release ?
It's not so much that we delay the new features, it's just that
On Mon, Apr 30, 2007 at 08:01:04AM +0200, Stefan Kaltenbrunner wrote:
Dave Page wrote:
Stefan Kaltenbrunner wrote:
This means that there is a huge rush of new code in pgAdmin's
development cycle, right at the time when we should be testing - making
the release process more and more rushed
Dave Page wrote:
Stefan Kaltenbrunner wrote:
Interesting ... so if you have a new feature (or a number of them) -
that is not directly depending on some sort of new backend feature - in
pgadmin you delay it until the next postgresql mjor release ?
It's not so much that we delay the new
Stefan Kaltenbrunner wrote:
No, but it's exactly the reason why we release with/just before
PostgreSQL. If we were offset by six months, we might find ourselves
having to do compatibility releases mid-cycle for the latest PostgreSQL
release. A change in pg_database such as we had previously
Tom Lane wrote:
[ thinks for a bit... ] What we need to expand is not so much the pool
of committers as the pool of reviewers. If a patch had been signed off
on by X number of reasonably-qualified people then it'd be fair to
consider that it could be committed. The tracking system you suggest
Stefan Kaltenbrunner wrote:
Simon Riggs wrote:
On Thu, 2007-04-26 at 23:13 -0400, Bruce Momjian wrote:
Our community could probably handle a few of these complex patches, but
the volume for this release is significantly higher than previous
releases. The community is doing a good job
Heikki Linnakangas wrote:
Simon Riggs wrote:
My thinking is to move to a two stage release process: Do one
production release annually, and one dev release at the 6 month
mid-point. That way each new release contains a manageable number of new
features and we have a realistic chance of
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
Simon Riggs wrote:
I would also suggest that 8.3 be labelled a dev release. We have a
reasonable number of fairly invasive patches, so we need a mechanism to
integrate them with reduced risk.
I would rather like to see patches we
Gregory Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
The postponed patches can be reviewed and committed early in 8.4, instead of
at the last minute in 8.3.
Given that some of those patches have been in the queue since last September
is there any reason to think they'll get
Lukas Kahwe Smith wrote:
Alvaro Herrera wrote:
Yeah; the agreement we had was that 8.3 would be a short release. So if
we're going to take too long to review and apply the outstanding patches
we have, we should rather push them to 8.4, get 8.3 released quickly and
then go on with the
Dave Page wrote:
2) Introduce a new patch management system. I suggest a web interface
through which patches be submitted. This would assign them an ID number,
and forward them to the patches list. The system would track any
responses to the initial email, logging the thread automatically
Dave Page wrote:
I'm not specifically talking about complex patches (nor am I talking at
all about bug tracking) - there are a variety of patches in the queue,
of varying complexity. Some have been there for months, and worse, some
of them recieved little or no feedback when submitted leaving
Andrew Dunstan wrote:
I don't think we need a sync point. I think we need to get better at
setting expectations and at managing the patch queue so that it gets
drained better all the time. Nothing can be more frustrating for patch
authors than to have patches in the queue for a very long
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
I like the idea of having a sync point mid cycle, however, what I'd like
to see even more is an improved system in which we put less pressure on
the few committers we have, and give them more freedom to commit patches
they may not
Every patch in the queue is ready for review. If we have bounced
something back for the author to fix, it gets removed from the queue.
As far as adding comments, again, this wasn't meant to be a community
resource, just my tracking system, and I have given feedback on the
status to any
Marc G. Fournier wrote
patches held over from feature freeze from the previous
release will be reviewed within two months of the tree re-opening
a. why 2 months? shouldn't they be given priority, period?
Yes, but they don't always seem to get it.
b. what happens after 2
Bruce Momjian wrote:
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
I like the idea of having a sync point mid cycle, however, what I'd like
to see even more is an improved system in which we put less pressure on
the few committers we have, and give them more freedom to commit patches
Bruce Momjian wrote:
Dave Page wrote:
2) Introduce a new patch management system. I suggest a web interface
through which patches be submitted. This would assign them an ID number,
and forward them to the patches list. The system would track any
responses to the initial email, logging the
Martin Langhoff wrote:
So - if you are committed to providing your gateway long term to
Florian, I'm happy to drop my gateway in favour of yours.
(Florian, before basing your code on either you should get a checkout of
Aidan's and mine and check that the tips of the branches you are working
Dave Page wrote:
In my original message I described my thinking:
- Developer submits patch, with additional info through a web interface.
- The web interface formats an email containing the patch description,
patch and any other info entered, assigns it a patch number, and
forwards it to the
Dave Page wrote:
Stefan Kaltenbrunner wrote:
This means that there is a huge rush of new code in pgAdmin's
development cycle, right at the time when we should be testing - making
the release process more and more rushed as each release of PostgreSQL
gets more efficient and adds more and more
* Florian G. Pflug [EMAIL PROTECTED] [070430 08:58]:
It seems as if git pulls all revisions of all files during the pull -
which it shouldn't do as far as I understand things - it should only
pull those objects referenced by some head, no?
Git pulls full history to a common ancestor on the
On Mon, Apr 30, 2007 at 07:27:10AM -0400, Bruce Momjian wrote:
Dave Page wrote:
I'm not specifically talking about complex patches (nor am I talking at
all about bug tracking) - there are a variety of patches in the queue,
of varying complexity. Some have been there for months, and worse,
Aidan Van Dyk wrote:
* Florian G. Pflug [EMAIL PROTECTED] [070430 08:58]:
It seems as if git pulls all revisions of all files during the pull -
which it shouldn't do as far as I understand things - it should only
pull those objects referenced by some head, no?
Git pulls full history to a
Hello!
I wanna know where can I find the source code that writes tuples on disk,
right now I'm reading about object persistence and I wanna see how it is
done in pgsql
I hope you can help me
regards
jorge
Tom Lane wrote:
[ redirecting to -hackers for wider comment ]
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane wrote:
LET_OS_MANAGE_FILESIZE is good way. I think one problem of this option I
fixed. It is size of offset. I went thru the code and did not see any
other problem there. However,
See http://www.postgresql.org/docs/8.2/interactive/storage.html
in code it is for example in
src/backend/storage/...
src/backend/utils/adt/...
src/backend/access/...
and very good also is
src/include/stroage/bufpage.h
I hope it helps
Zdenek
jorge alberto wrote:
Hello!
I
I'm taking over Simon's heap page diagnostic functions to get them into
shape for committing.
I'm thinking of having a new contrib-module for them: pgforensics. All
the new functions go there, and I'm also going to move bt_page_items,
bt_page_stats, and bt_metap functions from pgstattuple to
Heikki,
We're having a short 8.3 cycle because we wanted to shift our release
schedule from Autumn to Spring. That would get us back to releasing in
Autumn.
Er, no. We wanted to change the cycle to avoid having Feature Freeze occur at
midsummer (N. hemisphere) when many of our committers
On Mon, 2007-30-04 at 08:56 -0300, Heikki Linnakangaspgsql wrote:
Date: Mon, 30 Apr 2007 09:18:36 +0100
From: Heikki Linnakangas [EMAIL PROTECTED]
To: Tom Lane [EMAIL PROTECTED]
Cc: Dave Page [EMAIL PROTECTED], Simon Riggs
[EMAIL PROTECTED],
Bruce Momjian [EMAIL PROTECTED],
Marc Munro wrote:
On Mon, 2007-30-04 at 08:56 -0300, Heikki Linnakangaspgsql wrote:
Date: Mon, 30 Apr 2007 09:18:36 +0100
From: Heikki Linnakangas [EMAIL PROTECTED]
To: Tom Lane [EMAIL PROTECTED]
Cc: Dave Page [EMAIL PROTECTED], Simon Riggs
[EMAIL PROTECTED],
Bruce Momjian [EMAIL
[EMAIL PROTECTED] (Marc Munro) writes:
On Mon, 2007-30-04 at 08:56 -0300, Heikki Linnakangaspgsql wrote:
Date: Mon, 30 Apr 2007 09:18:36 +0100
From: Heikki Linnakangas [EMAIL PROTECTED]
To: Tom Lane [EMAIL PROTECTED]
Cc: Dave Page [EMAIL PROTECTED], Simon Riggs
[EMAIL PROTECTED],
Bruce
I have developed a small patch to optimizer/util/plancat.c that
eliminates one of hte caveats associated with constraint exclusions,
namely the inability to avoid searching tables based on the results of
stable functions. The new code expands non-volatile functions into
constant values so
OK, so posted. ;-)
To clarify for the larger audience: without the plain gss
mechanism, the gss-np mechanism provides exactly the same
functionality as the existing krb5 mechanism. It will properly
secure the initial connection, but will not do anything once the
connection is
Dave Page wrote:
In my original message I described my thinking:
- Developer submits patch, with additional info through a web interface.
- The web interface formats an email containing the patch description,
patch and any other info entered, assigns it a patch number, and
forwards it to
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Zdenek Kotala wrote:
Tom Lane wrote:
[ redirecting to -hackers for wider comment ]
Zdenek Kotala [EMAIL
Sounds good, though I am worried that forensics will not be a word
easily understood by non-native English speakers.
---
Heikki Linnakangas wrote:
I'm taking over Simon's heap page diagnostic functions to get them into
Marshall, Steve [EMAIL PROTECTED] writes:
I have developed a small patch to optimizer/util/plancat.c that
eliminates one of hte caveats associated with constraint exclusions,
namely the inability to avoid searching tables based on the results of
stable functions.
Do you not understand why
Excuse me for replying to myself, but maybe it would be clearer if I
said this the other way around:
The existing Kerberos support uses a C API that is not supported in
Java or on Windows, and probably never will be. If we want to
support Kerberos on *all* platforms (and if we want
Henry B. Hotz [EMAIL PROTECTED] writes:
I tend to regard this as a comparable migration to the Kerb4 - Kerb5
one. In time it should be a complete replacement. In time we will
be able to rip out the existing Kerb5 code.
Why in time and not immediately? Are there platforms that don't
Don't you want to maintain some interoperability between 8.2 client/
server and 8.3 server/client at least? If you put my patches in 8.3,
and they work as well as I hope, then in time could be as soon as
8.4, I suppose.
To answer the question more directly: I do not know of any platform
Henry B. Hotz [EMAIL PROTECTED] writes:
Don't you want to maintain some interoperability between 8.2 client/
server and 8.3 server/client at least?
Hm, you mean that what you called a C API change actually
break^H^H^H^H^Hchanges the on-the-wire protocol as well?
That sounds not very nice :-(
Yes, the wire protocol is different. Sorry. I can't help that.
As I said, I'm not adding any new functionality yet, just lots of
potential compatibility that isn't possible with the Kerberos API now
used. While there's no significant new functionality yet, at least
there's no regression
I believe the suggestion was to have an automated process that only ran
on known, sane patches. I don't think he was suggesting a mechanism for
the great unwashed masses to dump arbitrary code into and have it
applied in the buildfarm. You'd have an inventory of patches (you could
use a hash to
Naz Gassiep [EMAIL PROTECTED] writes:
Even if the patch inventory wasn't kept right up to date, this system
could potentially help many regression issues or bugs to surface sooner,
I just don't understand what this would accomplish. People run regressions
before submitting anyways. They can't
47 matches
Mail list logo
