On Sep 22, 2006, at 2:50 PM, Joshua D. Drake wrote:
And how were you planning to tell if a patch cam from a regular?
Hopefully
you weren't planning on blindly trusting the from header.
Misuse of the build farm in a way the effects other sites could
get the
project a big black eye, so you
On Wed, Sep 13, 2006 at 22:22:12 -0700,
Tom Dunstan [EMAIL PROTECTED] wrote:
That's a worthwhile point. How many patches come from the general
community vs out of the blue? Patches from regulars could probably get a
free pass, which might cut down the review burden substantially.
And how
On Fri, Sep 22, 2006 at 11:58:04AM -0500, Bruno Wolff III wrote:
On Wed, Sep 13, 2006 at 22:22:12 -0700,
Tom Dunstan [EMAIL PROTECTED] wrote:
That's a worthwhile point. How many patches come from the general
community vs out of the blue? Patches from regulars could probably get a
Jim C. Nasby wrote:
On Fri, Sep 22, 2006 at 11:58:04AM -0500, Bruno Wolff III wrote:
On Wed, Sep 13, 2006 at 22:22:12 -0700,
Tom Dunstan [EMAIL PROTECTED] wrote:
That's a worthwhile point. How many patches come from the general
community vs out of the blue? Patches from regulars could
Am Freitag, 15. September 2006 20:32 schrieb Tom Lane:
I've finally taken a close look at this patch, and I don't like it any
more than Peter does. The refactoring might or might not be good at its
core, but as presented it is horrid.
Joachim Wieland is in the process of reworking the
On Mon, Sep 18, 2006 at 01:13:45PM +0200, Peter Eisentraut wrote:
Joachim Wieland is in the process of reworking the original feature patch
(resetting commented out parameters) in a much more compact form. But it
turns out that there are a couple of very tricky situations involving custom
Joachim Wieland [EMAIL PROTECTED] writes:
I have the patch almost ready in the described form, if there is any chance
it will make it into 8.2 I will clean it up and post it ASAP but Peter wrote
me that chances are close to zero and so I stopped working on it for now.
If you'd mentioned it a
Peter Eisentraut [EMAIL PROTECTED] writes:
That does not mean that the patch is bad, and I certainly support the
feature change. But I can't efficiently review the patch. If someone
else wants to do it, go ahead.
I've finally taken a close look at this patch, and I don't like it any
more
Hi, Jeremy,
Jeremy Drake wrote:
Another possibility would be to test these patches in some kind of virtual
machine that gets blown away every X days, so that even if someone did get
something malicious in there it wouldn't last long.
Or just have a snapshot which is reverted after each
On Sat, Sep 02, 2006 at 09:26:36PM -0700, Joshua D. Drake wrote:
I just spent 1/2 hour fixing the multi-value UPDATE
patch for the code drift caused by UPDATE/RETURNING. The patch is a
simple grammar macro. Any coder could have taken that, reviewed it, and
applied it, but no one did.
Jim C. Nasby wrote:
There's been talk in the past of having some kind of system that
automatically attempts to build things that are in the patch queue, both
as an initial sanity-check and as a means to detect when something
bit-rots... perhaps it's becoming worthwhile to set that up.
After
Tom Dunstan wrote:
The idea was that patch authors could either run it manually or stick it
in a cron so they could get emailed when the patch no longer cleanly
applied, or when the patched source failed in make, make check etc.
Obviously my motivation was to keep the enum patch up to date
Alvaro Herrera wrote:
I submitted a patch to Andrew, but it needed a couple of tweaks
(disabling patching on vpath builds, for example) and I don't think I
ever got around to resubmitting it, but if there's more general interest
I'll do so.
Huh, why would you disable patching on vpath
Tom Dunstan wrote:
Alvaro Herrera wrote:
I submitted a patch to Andrew, but it needed a couple of tweaks
(disabling patching on vpath builds, for example) and I don't think I
ever got around to resubmitting it, but if there's more general interest
I'll do so.
Huh, why would you disable
Alvaro Herrera wrote:
Huh, but the patch can be applied with -R to revert it after the
buildfarm run ... the one problem I can see is if the patch fails for
some reason; for which I'd suggest running a patch --dry-run as a first
step, checking that it applies cleanly, and only continue in
Andrew Dunstan wrote:
Tom's idea of making a temp copy of the repo and patching that would work,
but if you're going to do that why do a vpath build anyway?
In this case, the answer is to make sure that your patch works when
*someone else* does a vpath build.
Regarding the idea of a list
Jim C. Nasby wrote:
There's been talk in the past of having some kind of system that
automatically attempts to build things that are in the patch queue, both
as an initial sanity-check and as a means to detect when something
bit-rots... perhaps it's becoming worthwhile to set that up.
After
On Sep 13, 2006, at 6:56 PM, Tom Dunstan wrote:
Regarding the idea of a list of approved patch authorisers, don't
we have
such a group now? i.e. committers.
Right, and if committers or others are willing to put in the time
required to verify that patches aren't nasty before going onto the
Jim Nasby wrote:
That's something I'd be willing to do. And for many people that aren't
committers but are still trusted in the community, we could probably
bypass the checking.
That's a worthwhile point. How many patches come from the general
community vs out of the blue? Patches from
On Wed, 13 Sep 2006, Tom Dunstan wrote:
Another possibility would be to test these patches in some kind of virtual
machine that gets blown away every X days, so that even if someone did get
something malicious in there it wouldn't last long.
Or just have a snapshot which is reverted after
Jeremy Drake wrote:
On Wed, 13 Sep 2006, Tom Dunstan wrote:
I was under the impression that most VM products are x86 centric, which
wouldn't lead to huge amounts of diversity in the buildfarm results. At least,
not as far as architecture goes.
I have played with QEmu (www.qemu.org) which is
On Fri, Sep 01, 2006 at 03:28:36PM -0400, Stephen Frost wrote:
Overall, I really think 8.2 is going to be an excellent release. I wish
autovacuum could have been enabled by default and I'd just like to ask,
now and I'll try to remember again once 8.2 is out, please let's turn it
on by default
Alvaro Herrera wrote:
Joshua D. Drake wrote:
It does not mean all those features are useful, they definitely are. I
am just trying to look at it from at:
WHIZ* BANG* POW* perspective.
Holy crap, Batman! This database can do
INSERT INTO foo VALUES (1,1, 'so long'), (42, 2, 'and
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, it's taken us the full month to get this far through the queue, so
I'd sure like to have more people on board reviewing next time. Alvaro
helped but I miss Neil Conway, and some other people have helped in the
On Sun, Sep 03, 2006 at 07:42:02PM -0400, Tom Lane wrote:
The hard part of this problem is finding a convenient way to capture
status data out of the community's conversations. I think when you find
a solution to that, you'll notice that email is not the problem.
In private groups (like
Andrew Sullivan wrote:
On Sun, Sep 03, 2006 at 07:42:02PM -0400, Tom Lane wrote:
The hard part of this problem is finding a convenient way to capture
status data out of the community's conversations. I think when you find
a solution to that, you'll notice that email is not the problem.
Tom Lane wrote:
AFAICS the bottom line here is that we need some intelligent filtering.
In the short run I doubt that we can have that except through human
gruntwork to filter the mail traffic and update a tracker database.
Maybe after we see such a system in operation for awhile, we can start
Andrew Dunstan wrote:
I spent months on a working party on these and similar issues a few
years back, in a commercial setting. One of the big issues is when you
start tracking something. Bugs are a pretty simple case. Features are
much harder to handle. Someone comes up with an idea. There is
Am Montag, 4. September 2006 04:10 schrieb Bruce Momjian:
Are you saying you don't like the patch,
That's it.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Oh, lots of grunt work. I can see that working, but at a high cost.
I doubt it. Let's just start with bugs, since that's the easy case
anyway. Our real volume is pretty low, so the cost of
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Without a reply from Peter, I have to assume the patch is valid.
To make it more explicit: I think the patch is stupid, but if someone
wants to review it, go ahead. But I am not comfortable with the if no
one objects, I'll
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Without a reply from Peter, I have to assume the patch is valid.
To make it more explicit: I think the patch is stupid, but if someone
wants to review it, go ahead. But I am not comfortable with the if no
Peter Eisentraut wrote:
Bruce Momjian wrote:
How many times do I have to say this: IT IS NOT A REFACTOR PATCH AS
REPORTED BY THE AUTHOR, AND PETER HAS NOT REFUTED THAT.
The initial patch was the feature plus some code refactoring included.
That was what the author said. I asked him to
Bruce Momjian wrote:
Why aren't more people involved? Is this such a thankless task? I
am starting to think so.
I can tell you exactly what my problem is. The tools are terrible. In
projects with a useful issue tracking system I can take small chunks
out of my day to contribute to
Tom Lane wrote:
Lukas Kahwe Smith [EMAIL PROTECTED] writes:
For example I have no expertise in coding on Postgres, but I think I
would be able to collect information from this mailinglist (like specs,
url's etc.) and put them in some issue tracker or wiki. I have done
exactly the same
Joshua D. Drake wrote:
I just spent 1/2 hour fixing the multi-value UPDATE
patch for the code drift caused by UPDATE/RETURNING. The patch is a
simple grammar macro. Any coder could have taken that, reviewed it, and
applied it, but no one did.
Perhaps that's because nobody but you
bruce wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Peter has made it pretty clear that he didn't care for the
refactorization aspect of that patch.
Peter asked why it was done, a good answer was given, and Peter did not
reply.
Au
Bruce Momjian wrote:
Without a reply from Peter, I have to assume the patch is valid.
To make it more explicit: I think the patch is stupid, but if someone
wants to review it, go ahead. But I am not comfortable with the if no
one objects, I'll just commit it mode that is sometimes going on.
On Sun, Sep 03, 2006 at 03:40:40PM -0400, Bruce Momjian wrote:
This is also an interesting example for a tracker. If we had one, all
discussion on the patch would be in one place, but I am thinking that
would require all posting to happen in a browser, or somehow have emails
tagged to attach
Martijn van Oosterhout kleptog@svana.org writes:
I assume other bug trackers have a similar feature...
Sadly no. That's precisely why I was pushing debbugs so hard earlier.
The weakest of them will send a content-free email saying *something* happened
to your issue and you have to click a
Gregory Stark wrote:
Martijn van Oosterhout kleptog@svana.org writes:
I assume other bug trackers have a similar feature...
Sadly no. That's precisely why I was pushing debbugs so hard earlier.
The weakest of them will send a content-free email saying *something* happened
to
Andrew Dunstan [EMAIL PROTECTED] writes:
As for remarks about old school unix hackers not liking web interfaces, I
think Tom's recent remarks relating to the 21st century were more than
apposite.
I like web interfaces well enough for the things they're good at.
Replacing e-mail is not one
Andrew Dunstan [EMAIL PROTECTED] writes:
As for remarks about old school unix hackers not liking web interfaces,
I think Tom's recent remarks relating to the 21st century were more than
apposite.
I don't see a big problem with using a web interface to search for
information --- they're good
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
As for remarks about old school unix hackers not liking web interfaces,
I think Tom's recent remarks relating to the 21st century were more than
apposite.
I don't see a big problem with using a web interface to search for
information
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
As for remarks about old school unix hackers not liking web interfaces,
I think Tom's recent remarks relating to the 21st century were more than
apposite.
I don't see a big problem with using a web interface to search for
Peter Eisentraut wrote:
Bruce Momjian wrote:
Without a reply from Peter, I have to assume the patch is valid.
To make it more explicit: I think the patch is stupid, but if someone
wants to review it, go ahead. But I am not comfortable with the if no
one objects, I'll just commit it mode
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Sun, Sep 03, 2006 at 03:40:40PM -0400, Bruce Momjian wrote:
This is also an interesting example for a tracker. If we had one, all
discussion on the patch would be in one place, but I am thinking that
would require all posting
Gregory Stark wrote:
Martijn van Oosterhout kleptog@svana.org writes:
I assume other bug trackers have a similar feature...
Sadly no. That's precisely why I was pushing debbugs so hard earlier.
Oh. That is bad.
The weakest of them will send a content-free email saying *something*
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
As for remarks about old school unix hackers not liking web interfaces,
I think Tom's recent remarks relating to the 21st century were more than
apposite.
I don't see a big problem with using a web interface to search for
Bruce Momjian [EMAIL PROTECTED] writes:
Oh, so the bug is tracked by being part of the email reply list. That
is a good idea. Now, how does that get assigned for non-bugs, like
patches? Does any email sent to the lists that doesn't already have a
bug number get one? That might be really
Bruce Momjian wrote:
Oh, so the bug is tracked by being part of the email reply list. That
is a good idea. Now, how does that get assigned for non-bugs, like
patches? Does any email sent to the lists that doesn't already have a
bug number get one? That might be really valuable.
It
Andrew Dunstan [EMAIL PROTECTED] writes:
Anyway, let me reiterate: bz has at least the start of an email reply
facility, and making that work if it doesn't already should not be
beyond us.
I agree that starting from scratch seems like a good way to waste a
lot of time. I don't have a
Tom Lane wrote:
AFAICS the bottom line here is that we need some intelligent filtering.
In the short run I doubt that we can have that except through human
gruntwork to filter the mail traffic and update a tracker database.
Maybe after we see such a system in operation for awhile, we can
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Oh, so the bug is tracked by being part of the email reply list. That
is a good idea. Now, how does that get assigned for non-bugs, like
patches? Does any email sent to the lists that doesn't already have a
bug number get one?
Bruce Momjian wrote:
Oh, lots of grunt work. I can see that working, but at a high cost.
I doubt it. Let's just start with bugs, since that's the easy case
anyway. Our real volume is pretty low, so the cost of maintaining it
should not be high. I am assuming we would not be including
Andrew Dunstan wrote:
Bruce Momjian wrote:
Oh, lots of grunt work. I can see that working, but at a high cost.
I doubt it. Let's just start with bugs, since that's the easy case
anyway. Our real volume is pretty low, so the cost of maintaining it
should not be high. I am assuming we
Andrew Dunstan [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Oh, lots of grunt work. I can see that working, but at a high cost.
I doubt it. Let's just start with bugs, since that's the easy case
anyway. Our real volume is pretty low, so the cost of maintaining it
should not be high. I
This is not that far different from the premise upon which you built
the buildfarm: that there were people out there able to provide machine
resources and a certain amount of admin time. The resources this
project requires are not those exactly, but why shouldn't we expect
that some people
Andrew Dunstan wrote:
It would make the process more transparent, which is something several
people have expressed a desire for.
Yes, the processes seems to work by having two of the most important
people waste time on getting information anyone else could collect, or
that the developer
Lukas Kahwe Smith wrote:
For example I have no expertise in coding on Postgres, but I think I
would be able to collect information from this mailinglist (like specs,
url's etc.) and put them in some issue tracker or wiki. I have done
exactly the same for PHP [1] (though there are rarely specs
On Fri, Sep 01, 2006 at 10:13:07PM -0400, Jonah H. Harris wrote:
On 9/1/06, Bruce Momjian [EMAIL PROTECTED] wrote:
I pummelled Jonah over the recursive query patch.
He did. Trust me on this... think I still have some bruises too :)
That wasn't productive. Getting it out in public that your
On Fri, Sep 01, 2006 at 09:46:02PM -0400, Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
It pulls my a mailbox file I use, and it does instant updates as
soon as I change it. It is a URL. Why do people care where it
is?
The complaint has been that not enough
On Sat, Sep 02, 2006 at 09:00:35AM +0200, Lukas Kahwe Smith wrote:
Actually I should add that I went ahead and created the PHP todo list on
my own, without any official blessing and one by one internals developer
have joined. Now its actively used in the entire release process.
That is the
Martijn van Oosterhout wrote:
I remember something about setting up a wiki for a todo list and pie
in the sky list. I thought it had promise, but until the wiki is
there we won't know...
I think the wiki is the prerequisite for many ideas about alternative
tracking and documentation
On Saturday 02 September 2006 07:14, David Fetter wrote:
On Fri, Sep 01, 2006 at 09:46:02PM -0400, Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
It pulls my a mailbox file I use, and it does instant updates as
soon as I change it. It is a URL. Why do people care
Lukas Kahwe Smith [EMAIL PROTECTED] writes:
For example I have no expertise in coding on Postgres, but I think I
would be able to collect information from this mailinglist (like specs,
url's etc.) and put them in some issue tracker or wiki. I have done
exactly the same for PHP [1] (though
Alvaro Herrera [EMAIL PROTECTED] writes:
Here's a completely novel idea: accept incremental patches.
I don't think it's as novel as all that --- personally I've always
preferred to tackle large projects incrementally.
I've been bitten by having stuff rejected because there was no immediate
On Sep 2, 2006, at 11:28 AM, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Here's a completely novel idea: accept incremental patches.
I don't think it's as novel as all that --- personally I've always
preferred to tackle large projects incrementally.
I think that accepting
Theo Schlossnagle [EMAIL PROTECTED] writes:
Additionally, what problem is accepting incremental patches supposed
to solve?
Keeping the individual patches reviewable is one useful goal.
We may be talking at cross-purposes here. The sort of thing I think
Alvaro is imagining is something like
On Friday 01 September 2006 19:42, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
On Fri, 1 Sep 2006, Tom Lane wrote:
My feeling is that we ought to bounce bitmap indexes and updatable views
as not being ready, accept all the contrib stuff, and try to get the
other items done in
Tom Lane wrote:
Theo Schlossnagle [EMAIL PROTECTED] writes:
Additionally, what problem is accepting incremental patches supposed
to solve?
Keeping the individual patches reviewable is one useful goal.
We may be talking at cross-purposes here. The sort of thing I think
Alvaro is imagining
Robert Treat wrote:
No offense, a whole lot of this thread seems to be positioned that way, but
the real problem seems to be we do not have enough patch reviewers. ISTM the
questions we should be asking are who can actually help out with patch review
and then ask those people why they
Robert Treat wrote:
On Saturday 02 September 2006 07:14, David Fetter wrote:
On Fri, Sep 01, 2006 at 09:46:02PM -0400, Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
It pulls my a mailbox file I use, and it does instant updates as
soon as I change it. It is
Peter Eisentraut wrote:
Martijn van Oosterhout wrote:
I remember something about setting up a wiki for a todo list and pie
in the sky list. I thought it had promise, but until the wiki is
there we won't know...
I think the wiki is the prerequisite for many ideas about alternative
tracking
Lukas Kahwe Smith wrote:
Robert Treat wrote:
No offense, a whole lot of this thread seems to be positioned that way, but
the real problem seems to be we do not have enough patch reviewers. ISTM
the
questions we should be asking are who can actually help out with patch
review
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Holy crap, Batman! This database can do
INSERT INTO foo VALUES (1,1, 'so long'), (42, 2, 'and thanks'),
(142857, 3, 'for all the fish')
now! We should be talking to more people about that!
That will make some MySQL users happy at least a
Lukas Kahwe Smith wrote:
Peter Eisentraut wrote:
Martijn van Oosterhout wrote:
I remember something about setting up a wiki for a todo list and pie
in the sky list. I thought it had promise, but until the wiki is
there we won't know...
I think the wiki is the prerequisite for many ideas
Joshua D. Drake wrote:
That wiki is wrong. :) It was set up wrong and configured wrong. It was
supposed to be for developers only.
There is also another wiki that is a trac based that was set up at dave
pages request (for slaves_to_www).
Setup something better, until then we can start
Lukas Kahwe Smith wrote:
Bruce Momjian wrote:
Lukas Kahwe Smith wrote:
Robert Treat wrote:
No offense, a whole lot of this thread seems to be positioned that way,
but
the real problem seems to be we do not have enough patch reviewers. ISTM
the
questions we should be asking
Bruce Momjian wrote:
Lukas Kahwe Smith wrote:
Robert Treat wrote:
No offense, a whole lot of this thread seems to be positioned that way, but
the real problem seems to be we do not have enough patch reviewers. ISTM the
questions we should be asking are who can actually help out with patch
On Sat, Sep 02, 2006 at 06:18:13PM +0200, Lukas Kahwe Smith wrote:
We have a wiki already:
http://wiki.postgresql.org/
I must have missed the annoucement, oh well...
Now I'm only familiar with twiki so maybe this sounds silly but:
Does it support sections? Like can you have a developer
Bruce Momjian wrote:
It seems that you have been the only busy bee so far, and we definitely
need more for this to work.
Yea, I was afraid that was the answer. :-(
But we have a few volunteers, like me for example.
Now don't say I was afraid that was the answer again or I might feel
On 2/9/06 17:18, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
Peter Eisentraut wrote:
Martijn van Oosterhout wrote:
I remember something about setting up a wiki for a todo list and pie
in the sky list. I thought it had promise, but until the wiki is
there we won't know...
I think the
Martijn van Oosterhout wrote:
On Sat, Sep 02, 2006 at 06:18:13PM +0200, Lukas Kahwe Smith wrote:
We have a wiki already:
http://wiki.postgresql.org/
I must have missed the annoucement, oh well...
Now I'm only familiar with twiki so maybe this sounds silly but:
wiki.postgresql.org is dead.
On Sat, Sep 02, 2006 at 06:38:30PM +0100, Dave Page wrote:
The wiki will be going shortly as it's not been setup in the way that was
agreed, nor is it being used for it's intended purpose. I'll put it right
when I get time from dealing with releases of everything I seem to be
involved in.
I
On 2/9/06 20:16, Martijn van Oosterhout kleptog@svana.org wrote:
On Sat, Sep 02, 2006 at 06:38:30PM +0100, Dave Page wrote:
The wiki will be going shortly as it's not been setup in the way that was
agreed, nor is it being used for it's intended purpose. I'll put it right
when I get time
Bruce Momjian [EMAIL PROTECTED] writes:
... The GUC comment/default patch had tons of
emails, but no other committers got involved to review or commit the
patch. Peter, who knows GUC well, looked at it, but said he didn't
review it enough.
Peter has made it pretty clear that he didn't care
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
... The GUC comment/default patch had tons of
emails, but no other committers got involved to review or commit the
patch. Peter, who knows GUC well, looked at it, but said he didn't
review it enough.
Peter has made it pretty
I just spent 1/2 hour fixing the multi-value UPDATE
patch for the code drift caused by UPDATE/RETURNING. The patch is a
simple grammar macro. Any coder could have taken that, reviewed it, and
applied it, but no one did.
Perhaps that's because nobody but you wanted it to go in.
We got tons
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Peter has made it pretty clear that he didn't care for the
refactorization aspect of that patch.
Peter asked why it was done, a good answer was given, and Peter did not
reply.
Au contraire, he's reiterated since then that he didn't
(I've already bounced this off the core committee, but it's time for
wider discussion.)
September is upon us and it doesn't seem like we are ready to ship
a beta. I think it's time to start making some hard choices.
In the main code I see these outstanding features/patches:
* bitmap indexes
*
My feeling is that we ought to bounce bitmap indexes and updatable views
as not being ready, accept all the contrib stuff, and try to get the
other items done in time for a beta at, say, the end of next week.
I'm not thrilled about postponing those two large items till 8.3, but
we are a month
Tom Lane wrote:
September is upon us and it doesn't seem like we are ready to ship
a beta. I think it's time to start making some hard choices.
In the main code I see these outstanding features/patches:
* bitmap indexes
* updatable views
IMHO these two should be bounced. They are big
Tom,
September is upon us and it doesn't seem like we are ready to ship
a beta. I think it's time to start making some hard choices.
In the main code I see these outstanding features/patches:
* bitmap indexes
* updatable views
* GUC variable reload + refactoring (previously applied and
* Tom Lane ([EMAIL PROTECTED]) wrote:
My feeling is that we ought to bounce bitmap indexes and updatable views
as not being ready, accept all the contrib stuff, and try to get the
other items done in time for a beta at, say, the end of next week.
I agree with bouncing these to get the beta
Josh Berkus josh@agliodbs.com writes:
Can you be a little clearer on which things are non-working patches, and
which things are pending due to lack of review?
The only things I currently want to reject as not having provided a
timely patch are bitmap indexes and updatable views. The other
Joshua D. Drake [EMAIL PROTECTED] writes:
My feeling is that we ought to bounce bitmap indexes and updatable views
as not being ready, accept all the contrib stuff, and try to get the
other items done in time for a beta at, say, the end of next week.
I know there is a lot of backend work that
Josh said nearly the same in core's discussion, but come now. The
updateable-view patch (in its current form) does not offer *one single
thing* you can't do today, indeed for many PG releases past; it just
saves writing out some tedious rules.
Sure, I can write the rules, you can write the
Josh Berkus wrote:
Tom,
September is upon us and it doesn't seem like we are ready to ship
a beta. I think it's time to start making some hard choices.
In the main code I see these outstanding features/patches:
* bitmap indexes
* updatable views
* GUC variable reload +
Tom Lane wrote:
I'm all for bouncing
stuff that's not ready to go, but bouncing stuff because we haven't
recruited enough code reviewers is just bad practice.
Well, it's taken us the full month to get this far through the queue, so
I'd sure like to have more people on board reviewing
1 - 100 of 139 matches
Mail list logo
