On Fri, 18 May 2007, Jim C. Nasby wrote:
Rather than trying to get something FAQ-perfect right now, can you at
least brain-dump what your current process is so that others can learn?
I've created a wiki page for this and added Heikki's tips:
Greg Smith wrote:
Heikki's great summary helps (I think the one piece I was screwing up
is covered there), and Pavan's comments adds some useful bits. The
still missing part is how to make a real branch to work in, which is
much easier to work with once you figure out how to do it than
Andrew Dunstan wrote:
What would making a branch actually do for you? The only advantage I can
see is that it will give you a way of checkpointing your files. As I
remarked upthread, I occasionally use RCS for that. But mostly I don't
actually bother. I don't see how you can do it reasonably
On Sat, 19 May 2007, Andrew Dunstan wrote:
What would making a branch actually do for you? The only advantage I can see
is that it will give you a way of checkpointing your files.
Exactly. It's not as bad now, but when I was getting started there were
lots of times I got something working
On 5/18/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
When I start working on a subject, I make a new checkout from the local
repository to a designated directory under pg_sandbox-directory. For
example, when I started working on the mvcc-safe cluster patch:
~/pg_sandbox$ cvs -d
Greg Smith wrote:
On Thu, 17 May 2007, David Fetter wrote:
Would you be interested in providing this meat? You're uniquely
qualified because your shins still smart from all the things you
barked them on :)
Unfortunately I'm temporarily on the other side of this problem; all the
time I have
Pavan Deolasee wrote:
For primitive version control, I make a diff after any significant changes:
~/pg_sandbox/pgsql.cluster$ cvs diff -cN cluster-mvcc-1.patch
I usually commit each version and tag the tree. That helps me to get
diff between two versions as well.
Doesn't that confuse
On 5/18/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Pavan Deolasee wrote:
For primitive version control, I make a diff after any significant
changes:
~/pg_sandbox/pgsql.cluster$ cvs diff -cN cluster-mvcc-1.patch
I usually commit each version and tag the tree. That helps me to get
On Thu, May 17, 2007 at 11:02:31PM -0400, Greg Smith wrote:
On Thu, 17 May 2007, David Fetter wrote:
Would you be interested in providing this meat? You're uniquely
qualified because your shins still smart from all the things you
barked them on :)
Unfortunately I'm temporarily on the
Jim C. Nasby wrote:
On Wed, May 16, 2007 at 07:48:10PM +0200, Magnus Hagander wrote:
Dave Page wrote:
I the current URLs represent the month, and the ID of the message as
it comes out of the mbox I believe. We could probably write a script
to dump a list of message IDs, directories and mbox
On Wed, May 16, 2007 at 11:50:26PM -0400, Greg Smith wrote:
On Tue, 15 May 2007, Jim C. Nasby wrote:
Speaking of reviewers... should we put some thought into how we can
increase the number of people who can review code? It seems that's one
of our biggest bottlenecks...
Having recently
Magnus Hagander wrote:
Right. Grabbing the msgid alone from them shouldn't be too hard though.
It's included in the meta-headers mhonarc sticks in each file, so it
should be a simple regex to find it.
Should be easier than that - when we import the existing messages from
the mbox files we
David Fetter wrote:
My main difficulty was figuring out a workable way to build a local mirror
of the code (so I could get off-line diffs), keep it in sync with the
development tree, while branching out working areas to evaluate patches or
do new development in. A good example walkthrough
On Wednesday 16 May 2007 13:02, Robert Haas wrote:
I care. I want a professional easy to understand and easy to maintain
that doesn't cause potential conflict with future and past development
syntax.
snip
If people have strong opinions about the syntax, why
were they not ALL expressed
On Thursday 17 May 2007 08:16, Andrew Dunstan wrote:
David Fetter wrote:
My main difficulty was figuring out a workable way to build a local
mirror of the code (so I could get off-line diffs), keep it in sync with
the development tree, while branching out working areas to evaluate
patches
On Thu, 17 May 2007, Andrew Dunstan wrote:
For this item at least the work has been done in showing how to set up a
local mirror using rsync instead of CVSup...although frankly it would be
better to import the information rather than just refer to the buildfarm
HOWTO.
The information in the
On Thu, 17 May 2007, Robert Treat wrote:
And really should probably be written up into FAQ section or a full on guide
for how do i get started hacking on postgresql?
To be clear here: while there are guides for new hackers out there, they
focus on the big picture. I walked from those with
Greg Smith wrote:
On Thu, 17 May 2007, Andrew Dunstan wrote:
For this item at least the work has been done in showing how to set
up a local mirror using rsync instead of CVSup...although frankly it
would be better to import the information rather than just refer to
the buildfarm HOWTO.
On Tue, May 15, 2007 at 04:52:16PM -0400, Alvaro Herrera wrote:
This is what happens with the Linux kernel. They have hundreds of
developers getting their hands dirty during a previous period. Then
2.6.20 is released; the 2.6.21 merge window opens, and all sort of
patches are flooded in.
Andrew Sullivan wrote:
On Tue, May 15, 2007 at 04:52:16PM -0400, Alvaro Herrera wrote:
This is what happens with the Linux kernel. They have hundreds of
developers getting their hands dirty during a previous period. Then
2.6.20 is released; the 2.6.21 merge window opens, and all sort of
Joshua D. Drake wrote:
Andrew Sullivan wrote:
On Tue, May 15, 2007 at 04:52:16PM -0400, Alvaro Herrera wrote:
This is what happens with the Linux kernel. They have hundreds of
developers getting their hands dirty during a previous period. Then
2.6.20 is released; the 2.6.21 merge window
Andrew Sullivan wrote:
On Tue, May 15, 2007 at 04:52:16PM -0400, Alvaro Herrera wrote:
This is what happens with the Linux kernel. They have hundreds of
developers getting their hands dirty during a previous period. Then
2.6.20 is released; the 2.6.21 merge window opens, and all sort of
On Thu, 17 May 2007, David Fetter wrote:
Would you be interested in providing this meat? You're uniquely
qualified because your shins still smart from all the things you
barked them on :)
Unfortunately I'm temporarily on the other side of this problem; all the
time I have to spare right now
Jim C. Nasby wrote:
On Tue, May 15, 2007 at 10:32:14PM +0200, Magnus Hagander wrote:
Stefan Kaltenbrunner wrote:
They are not stable. The items should point to the archives, which are
supposedly more stable. (I had already fixed one item in PatchStatus
this morning). Really it would be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, May 16, 2007 at 10:16:43AM +0900, Tatsuo Ishii wrote:
Stefan Kaltenbrunner wrote:
They are not stable. [...]
As I proposed for many times, why don't we add message number to each
subject line in mail? For example like this:
* Tatsuo Ishii [EMAIL PROTECTED] [070515 21:19]:
As I proposed for many times, why don't we add message number to each
subject line in mail? For example like this:
[HACKERS: 12345] Re: Not ready for 8.3
This way, we could always obtain stable (logical) pointer, without
reling on
* Tatsuo Ishii [EMAIL PROTECTED] [070515 21:19]:
As I proposed for many times, why don't we add message number to each
subject line in mail? For example like this:
[HACKERS: 12345] Re: Not ready for 8.3
This way, we could always obtain stable (logical) pointer, without
reling
I'm going to echo Bruce on this; I've mentioned that TSearch was going
into Core at conferences and the reaction from existing users has been
very enthusiastic, ranging from yippee! to about time!. Our users
hate the fact that FTS is a separate module.
Here here.
And with respect to the
Am Mittwoch, 16. Mai 2007 05:37 schrieb Josh Berkus:
In that case, we may need to talk
about branching earlier so that developers can work on the new version who
are frozen out of the in-process one.
Well, we could branch right now, but who is going to commit anything into that
new head
Am Mittwoch, 16. Mai 2007 05:37 schrieb Josh Berkus:
I'm going to echo Bruce on this; I've mentioned that TSearch was going into
Core at conferences and the reaction from existing users has been very
enthusiastic, ranging from yippee! to about time!. Our users hate the
fact that FTS is a
Robert Haas wrote:
Our users hate the fact that FTS is a separate module.
Here here.
Where? Where? Oh, you mean Hear Hear. (sorry - one of my pet peeves)
And with respect to the debate about syntax, who cares? I think I
prefer introducing real SQL-ish syntax over a bunch of pg_*
[EMAIL PROTECTED] wrote:
On Wed, May 16, 2007 at 10:16:43AM +0900, Tatsuo Ishii wrote:
Stefan Kaltenbrunner wrote:
They are not stable. [...]
As I proposed for many times, why don't we add message number to each
subject line in mail? For example like this:
[HACKERS: 12345] Re:
Tatsuo Ishii wrote:
* Tatsuo Ishii [EMAIL PROTECTED] [070515 21:19]:
As I proposed for many times, why don't we add message number to each
subject line in mail? For example like this:
[HACKERS: 12345] Re: Not ready for 8.3
This way, we could always obtain stable (logical)
* Tatsuo Ishii [EMAIL PROTECTED] [070516 07:23]:
Maybe. However I think subject-sequence has some advantages over
Message-Id:
- Easy to identify. Message-Id may not appear on some MUA with default
setting
- More handy than lengthy message Id
- Easy to detect messages not delivered,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, May 16, 2007 at 10:03:47AM -0400, Alvaro Herrera wrote:
[EMAIL PROTECTED] wrote:
[...]
There is just one remaining problem: Outlook and derivatives don't set
the In-Reply-To: nor References: headers. This breaks the threads (the
best the
Here here.
Where? Where? Oh, you mean Hear Hear. (sorry - one of my pet peeves)
Oops. Of course since it's in written form perhaps I should be writing
Read! Read! instead.
We do have a responsibility, I think, to keep the grammar fairly
clean,
so the answer to your question who
On Wed, May 16, 2007 at 08:58:44AM +0100, Dave Page wrote:
Jim C. Nasby wrote:
On Tue, May 15, 2007 at 10:32:14PM +0200, Magnus Hagander wrote:
Stefan Kaltenbrunner wrote:
They are not stable. The items should point to the archives, which are
supposedly more stable. (I had already fixed
Jim C. Nasby wrote:
How much visibility do we have into the mhonarc database? We should be
able to come up with a simple redirector that would point the old
mhonarc URLs to URLs for the new system...
coughdatabase?/cough
It's a file system. It simply generates HTML (or in our case) PHP files
On Wed, May 16, 2007 at 04:34:56PM +0100, Dave Page wrote:
How much visibility do we have into the mhonarc database? We should be
able to come up with a simple redirector that would point the old
mhonarc URLs to URLs for the new system...
coughdatabase?/cough
And here I thought the reason
Aidan Van Dyk wrote:
* Tatsuo Ishii [EMAIL PROTECTED] [070516 07:23]:
Maybe. However I think subject-sequence has some advantages over
Message-Id:
- Easy to identify. Message-Id may not appear on some MUA with default
setting
- More handy than lengthy message Id
- Easy
[EMAIL PROTECTED] (Aidan Van Dyk) writes:
* Tatsuo Ishii [EMAIL PROTECTED] [070516 07:23]:
Maybe. However I think subject-sequence has some advantages over
Message-Id:
- Easy to identify. Message-Id may not appear on some MUA with default
setting
- More handy than lengthy message Id
Robert Haas wrote:
hate the fact that FTS is a separate module.
Here here.
And with respect to the debate about syntax, who cares? I think I
prefer introducing real SQL-ish syntax over a bunch of pg_* functions,
but doing it either way is IMHO better than doing nothing.
I care. I want a
I care. I want a professional easy to understand and easy to maintain
that doesn't cause potential conflict with future and past development
syntax.
I agree with this. The point of my comment was that ISTM that an
arbitrary amount of time can be consumed determining the optimal syntax,
Jim C. Nasby wrote:
On Wed, May 16, 2007 at 04:34:56PM +0100, Dave Page wrote:
How much visibility do we have into the mhonarc database? We should be
able to come up with a simple redirector that would point the old
mhonarc URLs to URLs for the new system...
coughdatabase?/cough
And here I
Dave Page wrote:
I the current URLs represent the month, and the ID of the message as
it comes out of the mbox I believe. We could probably write a script
to dump a list of message IDs, directories and mbox positions I
imagine, and then import that into a new database.
Yeah, if the files
Andrew Dunstan wrote:
Josh Berkus wrote:
I think that may be where we're heading. In that case, we may need to
talk about branching earlier so that developers can work on the new
version who are frozen out of the in-process one.
I've argued this in the past. But be aware that it will make
On 5/16/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
I care. I want a professional easy to understand and easy to maintain
that doesn't cause potential conflict with future and past development
syntax.
You've just tempted me to create embedded SQL in assembly :)
--
Jonah H. Harris, Software
Magnus Hagander wrote:
It's been on my list to rewrite the whole archive system for a while
for various reasons. There is quite a bit of crossover with the patch
tracker I proposed so I was hoping to look at both together.
Let me know when you start on that...
Roger.
Same here - I've done
Richard Huxton wrote:
Magnus Hagander wrote:
It's been on my list to rewrite the whole archive system for a while
for various reasons. There is quite a bit of crossover with the patch
tracker I proposed so I was hoping to look at both together.
Let me know when you start on that...
Roger.
Dave Page wrote:
Richard Huxton wrote:
Magnus Hagander wrote:
It's been on my list to rewrite the whole archive system for a while
for various reasons. There is quite a bit of crossover with the patch
tracker I proposed so I was hoping to look at both together.
Let me know when you start on
On Wed, May 16, 2007 at 07:48:10PM +0200, Magnus Hagander wrote:
Dave Page wrote:
I the current URLs represent the month, and the ID of the message as
it comes out of the mbox I believe. We could probably write a script
to dump a list of message IDs, directories and mbox positions I
On Wed, May 16, 2007 at 09:32:44PM +0100, Richard Huxton wrote:
Dave Page wrote:
Richard Huxton wrote:
Magnus Hagander wrote:
It's been on my list to rewrite the whole archive system for a while
for various reasons. There is quite a bit of crossover with the patch
tracker I proposed so I was
On Tue, 15 May 2007, Jim C. Nasby wrote:
Speaking of reviewers... should we put some thought into how we can
increase the number of people who can review code? It seems that's one
of our biggest bottlenecks...
Having recently dragged myself from never seeing the code before to being
able to
Based on our progress during this feature freeze, we will not complete
the feature freeze until August/September. I think we need adjust
expectations about an 8.3 release date, and decide if we want to
radically change our work process.
Basically, to make a release anywhere near July, we need
Bruce Momjian [EMAIL PROTECTED] writes:
I think the only other thing we _could_ do is to re-open normal 8.3
development, so we aren't hampering updates to trivial parts of the
code. Many of the patches now in the queue had been developed for months
before 8.3 started, so the hope is that we
Bruce Momjian wrote:
Based on our progress during this feature freeze, we will not complete
the feature freeze until August/September. I think we need adjust
expectations about an 8.3 release date, and decide if we want to
radically change our work process.
Basically, to make a release
Joshua D. Drake wrote:
Bruce Momjian wrote:
Based on our progress during this feature freeze, we will not complete
the feature freeze until August/September. I think we need adjust
expectations about an 8.3 release date, and decide if we want to
radically change our work process.
Joshua D. Drake wrote:
Patch status:
http://developer.postgresql.org/index.php/Todo:PatchStatus
If... this is actually a problem (I leave to other committers and
reviewers to comment) then I suggest we push all patches without a
reviewer as of now to 8.4.
Leaving only those
Bruce Momjian [EMAIL PROTECTED] writes:
Joshua D. Drake wrote:
Bruce Momjian wrote:
Based on our progress during this feature freeze, we will not complete
the feature freeze until August/September. I think we need adjust
expectations about an 8.3 release date, and decide if we want to
Joshua D. Drake wrote:
FYI, whoever did that Todo:Patch status, Bravo! That is easily one of
the smallest but best improvements to the process I have seen in recent
memory.
well bruce asked for something like that:
http://archives.postgresql.org/pgsql-hackers/2007-05/msg00249.php
and I
Bruce,
Realistically I just don't see getting everything in the ToDo patch list in;
my vote is that we start deferring stuff for 8.4 if it doesn't have a
reviewer, except for items which were submitted early in the cycle (and to
whom it would be unfair).
If that means shortening the 8.4
That is not fair to patch submitters, and pushes the problem to 8.4,
where it will be no better.
If it isn't done, it isn't done. We aren't dropping the patch. The patch
has been accepted, just not reviewed. It is just delayed.
Sure it is, if we have a short release cycle. There are plenty
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think the only other thing we _could_ do is to re-open normal 8.3
development, so we aren't hampering updates to trivial parts of the
code. Many of the patches now in the queue had been developed for months
before 8.3 started,
We have new patch available
http://www.sigaev.ru/misc/tsearch_core-0.47.gz
to sync with CVS HEAD.
Oleg
On Tue, 15 May 2007, Joshua D. Drake wrote:
Bruce Momjian wrote:
Based on our progress during this feature freeze, we will not complete
the feature freeze until August/September. I think
[EMAIL PROTECTED] (Josh Berkus) writes:
Bruce,
Realistically I just don't see getting everything in the ToDo patch
list in; my vote is that we start deferring stuff for 8.4 if it
doesn't have a reviewer, except for items which were submitted early
in the cycle (and to whom it would be
On Tue, 15 May 2007, Joshua D. Drake wrote:
Tsearch2 in core. I know that Tom has some reservations, he I and Treat all
commented on how it was done and to my knowledge those reservations have not
been resolved.
We'd like to know about these reservations. If I understand you mean there
are
Joshua D. Drake wrote:
[...]
Concurrent psql, nifty but still trying to decide on actual interface.
Full Page Writes Improvement, doesn't actually do anything *yet* (as far
as I can tell) it just makes it so something can be done in the future.
It is also apparently a small patch.
UTF8
Oleg Bartunov wrote:
On Tue, 15 May 2007, Joshua D. Drake wrote:
Tsearch2 in core. I know that Tom has some reservations, he I and
Treat all commented on how it was done and to my knowledge those
reservations have not been resolved.
We'd like to know about these reservations. If I
Stefan Kaltenbrunner wrote:
Joshua D. Drake wrote:
PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
developed outside of core. Don't get me wrong I like the feature but it
can take advantage of facilities outside of core.
url fixed - I wonder why we had so much
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
Joshua D. Drake wrote:
PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
developed outside of core. Don't get me wrong I like the feature but it
can take advantage of facilities outside of core.
url fixed - I wonder
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
Joshua D. Drake wrote:
PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
developed outside of core. Don't get me wrong I like the feature but it
can take advantage of facilities outside of core.
url fixed - I wonder
They are not stable. The items should point to the archives, which are
supposedly more stable. (I had already fixed one item in PatchStatus
this morning). Really it would be much nicer to have links using the
Message-Id but I doubt that's at all doable.
I use this all the time:
Stefan Kaltenbrunner wrote:
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
Joshua D. Drake wrote:
PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
developed outside of core. Don't get me wrong I like the feature but it
can take advantage of facilities
Stefan Kaltenbrunner wrote:
They are not stable. The items should point to the archives, which are
supposedly more stable. (I had already fixed one item in PatchStatus
this morning). Really it would be much nicer to have links using the
Message-Id but I doubt that's at all doable.
hrm -
Aidan Van Dyk wrote:
They are not stable. The items should point to the archives, which are
supposedly more stable. (I had already fixed one item in PatchStatus
this morning). Really it would be much nicer to have links using the
Message-Id but I doubt that's at all doable.
I use
On Tue, 15 May 2007, Joshua D. Drake wrote:
Oleg Bartunov wrote:
On Tue, 15 May 2007, Joshua D. Drake wrote:
Tsearch2 in core. I know that Tom has some reservations, he I and Treat
all commented on how it was done and to my knowledge those reservations
have not been resolved.
We'd like to
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think the only other thing we _could_ do is to re-open normal 8.3
development, so we aren't hampering updates to trivial parts of the
code. Many of the patches now in the queue had been developed for months
before 8.3
Josh Berkus wrote:
Bruce,
Realistically I just don't see getting everything in the ToDo patch list in;
my vote is that we start deferring stuff for 8.4 if it doesn't have a
reviewer, except for items which were submitted early in the cycle (and to
whom it would be unfair).
It seems
Joshua D. Drake wrote:
That is not fair to patch submitters, and pushes the problem to 8.4,
where it will be no better.
If it isn't done, it isn't done. We aren't dropping the patch. The patch
has been accepted, just not reviewed. It is just delayed.
Delayed isn't rejected, but it isn't
Andrew Dunstan wrote:
I think the only other thing we _could_ do is to re-open normal 8.3
development, so we aren't hampering updates to trivial parts of the
code. Many of the patches now in the queue had been developed for months
before 8.3 started, so the hope is that we wouldn't have
Bruce Momjian wrote:
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think the only other thing we _could_ do is to re-open normal 8.3
development, so we aren't hampering updates to trivial parts of the
code. Many of the patches now in the queue had been developed for
Chris Browne wrote:
[EMAIL PROTECTED] (Josh Berkus) writes:
Bruce,
Realistically I just don't see getting everything in the ToDo patch
list in; my vote is that we start deferring stuff for 8.4 if it
doesn't have a reviewer, except for items which were submitted early
in the cycle (and
Oleg Bartunov wrote:
On Tue, 15 May 2007, Joshua D. Drake wrote:
Oleg Bartunov wrote:
On Tue, 15 May 2007, Joshua D. Drake wrote:
Tsearch2 in core. I know that Tom has some reservations, he I and
Treat all commented on how it was done and to my knowledge those
reservations have not been
Joshua D. Drake wrote:
Oleg Bartunov wrote:
On Tue, 15 May 2007, Joshua D. Drake wrote:
Tsearch2 in core. I know that Tom has some reservations, he I and
Treat all commented on how it was done and to my knowledge those
reservations have not been resolved.
We'd like to know about
On Tue, 15 May 2007, Joshua D. Drake wrote:
Oleg Bartunov wrote:
On Tue, 15 May 2007, Joshua D. Drake wrote:
Oleg Bartunov wrote:
On Tue, 15 May 2007, Joshua D. Drake wrote:
Tsearch2 in core. I know that Tom has some reservations, he I and Treat
all commented on how it was done and to my
Oleg Bartunov wrote:
On Tue, 15 May 2007, Joshua D. Drake wrote:
Tsearch2 in core. I know that Tom has some reservations, he I and Treat all
commented on how it was done and to my knowledge those reservations have
not
been resolved.
We'd like to know about these reservations. If I
Stefan Kaltenbrunner wrote:
PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
developed outside of core. Don't get me wrong I like the feature but it
can take advantage of facilities outside of core.
url fixed - I wonder why we had so much of them and all those
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
Joshua D. Drake wrote:
PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
developed outside of core. Don't get me wrong I like the feature but it
can take
Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
developed outside of core. Don't get me wrong I like the feature but it
can take advantage of facilities outside of core.
url fixed - I wonder why we had so much
Bruce Momjian wrote:
Oleg Bartunov wrote:
This is a good example of how developers can get frustrated. Pushing a
patch to 8.4 that was completed before 8.3 feature freeze is guaranteed
to add to that --- and if we lose our developers, we might as well shut
down the PostgreSQL project.
Let's
Alvaro Herrera wrote:
Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
developed outside of core. Don't get me wrong I like the feature but it
can take advantage of facilities outside of core.
url fixed - I wonder why we
Joshua D. Drake wrote:
Bruce Momjian wrote:
Oleg Bartunov wrote:
This is a good example of how developers can get frustrated. Pushing a
patch to 8.4 that was completed before 8.3 feature freeze is guaranteed
to add to that --- and if we lose our developers, we might as well shut
down
Bruce Momjian wrote:
Joshua D. Drake wrote:
One good thing is that we have community discussion this now, so at
least we are focusing on it.
Agreed, but it certainly is not a critical mass problem either. We are
starting to bounce off the wall, and are starting to take a step back to
On Tue, May 15, 2007 at 12:42:28PM -0400, Bruce Momjian wrote:
Joshua D. Drake wrote:
Patch status:
http://developer.postgresql.org/index.php/Todo:PatchStatus
If... this is actually a problem (I leave to other committers and
reviewers to comment) then I suggest we push all
On Tue, May 15, 2007 at 10:32:14PM +0200, Magnus Hagander wrote:
Stefan Kaltenbrunner wrote:
They are not stable. The items should point to the archives, which are
supposedly more stable. (I had already fixed one item in PatchStatus
this morning). Really it would be much nicer to have
Jim C. Nasby wrote:
On Tue, May 15, 2007 at 12:42:28PM -0400, Bruce Momjian wrote:
Joshua D. Drake wrote:
Patch status:
http://developer.postgresql.org/index.php/Todo:PatchStatus
If... this is actually a problem (I leave to other committers and
reviewers to
Jim C. Nasby wrote:
On Tue, May 15, 2007 at 10:32:14PM +0200, Magnus Hagander wrote:
Stefan Kaltenbrunner wrote:
They are not stable. The items should point to the archives, which are
supposedly more stable. (I had already fixed one item in PatchStatus
this morning). Really it would
On Tue, May 15, 2007 at 07:01:39PM -0400, Bruce Momjian wrote:
Unless you're really in love with doing that sort of thing it's really
good that someone else did it. You're one of a handful of folks that can
actually review patches, while there's any number of us that can update
a wiki.
Jim C. Nasby wrote:
On Tue, May 15, 2007 at 07:01:39PM -0400, Bruce Momjian wrote:
Unless you're really in love with doing that sort of thing it's really
good that someone else did it. You're one of a handful of folks that can
actually review patches, while there's any number of us that
Stefan Kaltenbrunner wrote:
They are not stable. The items should point to the archives, which are
supposedly more stable. (I had already fixed one item in PatchStatus
this morning). Really it would be much nicer to have links using the
Message-Id but I doubt that's at all doable.
1 - 100 of 106 matches
Mail list logo
