On Thu, Aug 27, 2009 at 12:03:05AM +0200, Dimitri Fontaine wrote:
> Hi,
>
> Peter Eisentraut writes:
> > On ons, 2009-08-26 at 14:26 -0400, Robert Haas wrote:
> >> Sure, but an aimless mandate to do testing for 4 (or 8, or 12) months
> >> doesn't necessarily buy you much, either. I'm good at foc
Josh Berkus wrote:
> Bruce,
>
> > I am not sure what other checklist items there would be (or I am
> > refusing to divulge).
>
> Hopefully the last is a joke. ;-)
Yes.
> So, the only post-CF tasks are issues with specific patches? This seems
> resolvable, especially if we take a hard line with
Bruce,
> I am not sure what other checklist items there would be (or I am
> refusing to divulge).
Hopefully the last is a joke. ;-)
So, the only post-CF tasks are issues with specific patches? This seems
resolvable, especially if we take a hard line with patch readiness.
There isn't anything el
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > The issues are different for every commitfest-beta period, so I have
> > no idea what to list there, but we do alway have an open issues wiki
> > that is maintained, at least for the most recent releases.
>
> After a quick search of the wiki,
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > it gets no easier to make the decisions later rather than now. The
> > delay forces us to make a final decision. We often had months to
> > make the decision earlier, but didn't.
>
> So you're advocating that we find a way to force more tim
On sön, 2009-08-30 at 21:09 -0400, Robert Haas wrote:
> I really can't understand why it isn't possible for us to find a way
> to make an annual release happen, and with more than 8-12 weeks of
> development time (ie non-CommitFest non-beta) available during that
> year. I understand that there is
Bruce Momjian wrote:
> it gets no easier to make the decisions later rather than now. The
> delay forces us to make a final decision. We often had months to
> make the decision earlier, but didn't.
So you're advocating that we find a way to force more timely
decisions?
-Kevin
--
Sent vi
Bruce Momjian wrote:
> The issues are different for every commitfest-beta period, so I have
> no idea what to list there, but we do alway have an open issues wiki
> that is maintained, at least for the most recent releases.
After a quick search of the wiki, it appears that the list for 8.4
wa
On Mon, Aug 31, 2009 at 2:20 PM, Bruce Momjian wrote:
> Knowing about the problem usually isn't hard , e.g. \df, but getting
> agreement on them is. One nifty idea would be to do a commit-fest for
> open items so we can get to beta.
I like that idea very much.
> The last commit-fest usually is l
Josh Berkus wrote:
> Bruce,
>
> > Huh, who has asked for a list from me? This entire post is mostly
> > over-the-top and not worth responding to.
>
> To quote myself:
>
> > Post-CF:
> > Make a list (now, not in January) of the tasks which need to be done
> > between CFend and Beta. We'll f
Joshua D. Drake wrote:
> On Mon, 2009-08-31 at 13:59 -0400, Bruce Momjian wrote:
> > Robert Haas wrote:
> > > On Mon, Aug 31, 2009 at 1:57 PM, Bruce Momjian wrote:
> > > > Josh Berkus wrote:
> > > >> Per the above, it would not. ?It would make things worse. ?This has
> > > >> been
> > > >> true at
Robert Haas wrote:
> That having been said, I think there is a legitimate concern about
> organizing and documenting the steps that are required to get a
> release out the door. A number of people have said (on this thread
> and previous ones) that we didn't know what we were supposed to be
> doin
Bruce,
> Huh, who has asked for a list from me? This entire post is mostly
> over-the-top and not worth responding to.
To quote myself:
> Post-CF:
> Make a list (now, not in January) of the tasks which need to be done
> between CFend and Beta. We'll find that some of them could be done b
On Mon, 2009-08-31 at 13:59 -0400, Bruce Momjian wrote:
> Robert Haas wrote:
> > On Mon, Aug 31, 2009 at 1:57 PM, Bruce Momjian wrote:
> > > Josh Berkus wrote:
> > >> Per the above, it would not. ?It would make things worse. ?This has been
> > >> true at every other OSS project I've seen documented
On Mon, Aug 31, 2009 at 1:59 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Aug 31, 2009 at 1:57 PM, Bruce Momjian wrote:
>> > Josh Berkus wrote:
>> >> Per the above, it would not. ?It would make things worse. ?This has been
>> >> true at every other OSS project I've seen documented (disa
Robert Haas wrote:
> On Mon, Aug 31, 2009 at 1:57 PM, Bruce Momjian wrote:
> > Josh Berkus wrote:
> >> Per the above, it would not. ?It would make things worse. ?This has been
> >> true at every other OSS project I've seen documented (disastrously so
> >> with MySQL); there is no reason to believe
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > Yep, the bottom line here is that patches get into CVS, but issues
> > come up related to the patch, and we keep looking for good fixes,
> > but once the final commit-fest is over, we _have_ to fix these
> > issues.
>
> If, hypothetically, it
On Mon, Aug 31, 2009 at 1:57 PM, Bruce Momjian wrote:
> Josh Berkus wrote:
>> Per the above, it would not. It would make things worse. This has been
>> true at every other OSS project I've seen documented (disastrously so
>> with MySQL); there is no reason to believe that Postgres would be any
>>
Josh Berkus wrote:
> Per the above, it would not. It would make things worse. This has been
> true at every other OSS project I've seen documented (disastrously so
> with MySQL); there is no reason to believe that Postgres would be any
> different.
>
> I also do not see why you are so resistant
Bruce Momjian wrote:
> Yep, the bottom line here is that patches get into CVS, but issues
> come up related to the patch, and we keep looking for good fixes,
> but once the final commit-fest is over, we _have_ to fix these
> issues.
If, hypothetically, it might hold up the release for two wee
On Mon, 2009-08-31 at 10:30 -0700, Josh Berkus wrote:
> >>> Another solution would be to make major releases less frequent.
> >> That's not a solution and you know it.
> >
> > I do?
>
> Ok, here's the reasons it's not a solution:
> Per the above, it would not. It would make things worse. This
>>> Another solution would be to make major releases less frequent.
>> That's not a solution and you know it.
>
> I do?
Ok, here's the reasons it's not a solution:
1) having a longer development cycle would frustrate many users who want
new features sooner, not later. The current 1 year is a g
On Sat, Aug 29, 2009 at 1:05 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> Both committers and non-committers are currently suffering from the
>> fact that there is not a lot of time in the year which is set aside
>> for development, i.e. neither CommitFest-time nor beta-time. To fix
>> this pr
Josh Berkus wrote:
> Bruce,
>
> >> None of those ideas have gotten a single vote of confidence
> >> from you or Bruce. What's your suggestion?
> >
> > Another solution would be to make major releases less frequent.
>
> That's not a solution and you know it.
I do?
> Our development cycle has t
Bruce,
>> None of those ideas have gotten a single vote of confidence
>> from you or Bruce. What's your suggestion?
>
> Another solution would be to make major releases less frequent.
That's not a solution and you know it.
Our development cycle has to change with the growth of the project. I
Tom Lane wrote:
> "Kevin Grittner" writes:
> > Robert Haas wrote:
> >> The final CommitFest began November 11, 2008. It closed March 25,
> >> 2009 (+ 144 days). Beta1 was released April 15, 2009 (+ 21 days).
>
> > I'm not entirely clear on what was happening during the 21 days
> > between th
Robert Haas wrote:
> Both committers and non-committers are currently suffering from the
> fact that there is not a lot of time in the year which is set aside
> for development, i.e. neither CommitFest-time nor beta-time. To fix
> this problem, we can:
>
> 1. Make CommitFests shorter.
> 2. Make C
On Fri, 2009-08-28 at 10:55 -0700, Josh Berkus wrote:
> Here is my proposal for CFs for this year:
>
> We do four CFs, July 15, September 15, November 15, and January 15.
>
> However, we rigidly apply the 30-day deadline for the January 15 CF.
> That is, anything which is not completely ready f
Folks,
Here is my proposal for CFs for this year:
We do four CFs, July 15, September 15, November 15, and January 15.
However, we rigidly apply the 30-day deadline for the January 15 CF.
That is, anything which is not completely ready for commit on February
14 gets punted to the next version. N
Ron Mayer wrote:
> Josh Berkus wrote:
>> There's some very good reasons for the health of the project to
>> have specific release dates and stick to them.
>
> Help me understand why?
I don't know how many places are like this, but to get any significant
staff or hardware resources officially
Greg Stark wrote:
> They basically don't do any integration testing and leave that up to
> the distributions now. Instead they have an "rc" release *every week*
> like clockwork and every 2-3 months the last one becomes a new version
> regardless of whether there's any notable new feature.
They h
On Fri, Aug 28, 2009 at 7:35 AM, Greg Smith wrote:
> It's really amazing that a useful result ever comes out of this model at
> all, and I know I'm not alone that I presume all Linux kernel releases are
> too full of bugs to be useful until I've proven otherwise with my own QA.
>
> If the core Post
On Thu, Aug 27, 2009 at 08:02:03PM -0700, Ron Mayer wrote:
> Andrew Dunstan wrote:
> > I don't know of anyone who is likely to want to try out alphas in their
> > normal development environments. The client I approached was
> > specifically prepared to test beta releases that way.
>
> Perhaps end-
Greg Smith wrote:
The Linux kernel developers are very clear that they don't care one
bit about testing for stability or lack of data loss in any
system-oriented way. That's somebody else's job now, typically the
Linux distributor who decides which of the kernels floating around are
the m
On Thu, Aug 27, 2009 at 09:38:15PM +0200, Dimitri Fontaine wrote:
> Exactly, and I think that what we're missing here is a simple tool for
> our users to check a new PostgreSQL release against their existing
> application.
>
> We already know how to either log all queries and analyze the log files
On Thu, 27 Aug 2009, Ron Mayer wrote:
The Linux kernel seems to do fine with a "when it is ready" cycle,
where some releases(2.6.24) take twice the time of others(2.6.28)[1,2].
[2] http://fblinux.freebase.com/view/base/fblinux/views/linux_kernel_release
That link has bad data. If you check th
On Fri, Aug 28, 2009 at 4:39 AM, Ron Mayer wrote:
> Josh Berkus wrote:
>> There's some very good reasons for the health of the project to have
>> specific release dates and stick to them.
>
> Help me understand why?
>
> The Linux kernel seems to do fine with a "when it is ready" cycle,
> where some
Josh Berkus wrote:
> There's some very good reasons for the health of the project to have
> specific release dates and stick to them.
Help me understand why?
The Linux kernel seems to do fine with a "when it is ready" cycle,
where some releases(2.6.24) take twice the time of others(2.6.28)[1,2]
Andrew Dunstan wrote:
> I don't know of anyone who is likely to want to try out alphas in their
> normal development environments. The client I approached was
> specifically prepared to test beta releases that way.
Perhaps end-users won't, but I think companies who develop software that
works on t
On Thu, Aug 27, 2009 at 6:09 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Robert Haas wrote:
>>> The final CommitFest began November 11, 2008. It closed March 25,
>>> 2009 (+ 144 days). Beta1 was released April 15, 2009 (+ 21 days).
>
>> I'm not entirely clear on what was happening during
Simon,
> The level of detailed planning happening now is a change for the
> community and in general I think it's a good thing. In the past we've
> always said it will be shipped when it's ready, and now we seem to be
> caught by our own rules. There's no need to make hard decisions now.
> Let's k
David Fetter wrote:
How about something in the alphas to the effect of,
Using PostgreSQL?
Have a development server to spare?
Try your application stack on alpha1!
We'd love to hear back. Functionality, performance, you name it.
I don't know of anyone who is likely to
On Thu, Aug 27, 2009 at 03:04:20PM -0400, Robert Haas wrote:
> On Thu, Aug 27, 2009 at 2:54 PM, Peter Eisentraut wrote:
> > On tor, 2009-08-27 at 09:58 -0400, Robert Haas wrote:
> >> To get positive results in which you can have confidence, you
> >> have to know that the testing which was done actu
"Kevin Grittner" writes:
> Robert Haas wrote:
>> The final CommitFest began November 11, 2008. It closed March 25,
>> 2009 (+ 144 days). Beta1 was released April 15, 2009 (+ 21 days).
> I'm not entirely clear on what was happening during the 21 days
> between the end of the CommitFest and an
Kevin Grittner escribió:
> Robert Haas wrote:
>
> > The final CommitFest began November 11, 2008. It closed March 25,
> > 2009 (+ 144 days). Beta1 was released April 15, 2009 (+ 21 days).
>
> I'm not entirely clear on what was happening during the 21 days
> between the end of the CommitFest
Robert Haas escribió:
> Of course I don't think we'd actually need to start a CommitFest quite
> as quickly as we did this time, because with a shorter release cycle
> there ought to be a lot less patches already accumulated by the time
> we release, especially if there are clearly defined tasks f
Robert Haas wrote:
> The final CommitFest began November 11, 2008. It closed March 25,
> 2009 (+ 144 days). Beta1 was released April 15, 2009 (+ 21 days).
I'm not entirely clear on what was happening during the 21 days
between the end of the CommitFest and and the release of beta1. I
seem
On Thu, Aug 27, 2009 at 04:22:58PM -0400, Jonah H. Harris wrote:
> On Thu, Aug 27, 2009 at 3:53 PM, David Fetter wrote:
>
> > > I would appreciate it if somebody could send out some messages
> > > of calm, while I/we work. The time for open review will come
> > > around soon enough.
> >
> > With
and...@dunslane.net (Andrew Dunstan) writes:
> Actually, what I had in mind was getting people to run their
> applications etc. in some non-production environment on the beta. I
> talked to a client today and he said "sure, we have several
> development environments and we can put one or two on the
On Thu, Aug 27, 2009 at 3:56 PM, Alvaro
Herrera wrote:
> Robert Haas escribió:
>> What I want to do is address the concern about too much of any given
>> year being consumed by beta and CommitFest. I'm not sure I know how
>> to do that though.
>
> How much time were we in beta? I thought most tim
On Thu, Aug 27, 2009 at 3:53 PM, David Fetter wrote:
> > I would appreciate it if somebody could send out some messages of
> > calm, while I/we work. The time for open review will come around
> > soon enough.
>
> With all due respect, the time for open review is now. You have
> already tried clo
Robert Haas escribió:
> What I want to do is address the concern about too much of any given
> year being consumed by beta and CommitFest. I'm not sure I know how
> to do that though.
How much time were we in beta? I thought most time was spent trying to
get to beta in the first place.
--
Alv
On Thu, Aug 27, 2009 at 08:48:43PM +0100, Simon Riggs wrote:
>
> On Sun, 2009-08-23 at 01:57 -0400, Tom Lane wrote:
> > Robert Haas writes:
> > > I posted a note about a week ago which drew far less commentary
> > > than I expected, regarding the timetable for the release of 8.5.
> >
> > > http:
On Sun, 2009-08-23 at 01:57 -0400, Tom Lane wrote:
> Robert Haas writes:
> > I posted a note about a week ago which drew far less commentary than I
> > expected, regarding the timetable for the release of 8.5.
>
> > http://archives.postgresql.org/pgsql-hackers/2009-08/msg01256.php
>
> > Perhaps
Hi,
Robert Haas writes:
> On Thu, Aug 27, 2009 at 2:54 PM, Peter Eisentraut wrote:
>> We have regression tests. They could and should be expanded. That's a
>> developer job, and we can start working on that now. But this
>> discussion was about what to do during beta. And I think during beta
On Thu, Aug 27, 2009 at 2:54 PM, Peter Eisentraut wrote:
> On tor, 2009-08-27 at 09:58 -0400, Robert Haas wrote:
>> To get positive results in which you can have confidence, you have to
>> know that the testing which was done actually did a reasonably good
>> job exercising the code in a way that w
On tor, 2009-08-27 at 09:58 -0400, Robert Haas wrote:
> To get positive results in which you can have confidence, you have to
> know that the testing which was done actually did a reasonably good
> job exercising the code in a way that would have flushed out bugs, had
> any been present. That soun
Greg Stark writes:
> On Thu, Aug 27, 2009 at 3:11 PM, Tom Lane wrote:
>> ... However this is quite haphazard since (a) the regression tests
>> aren't especially designed to exercise all of the WAL logic, and (b)
>> pg_dump might not show the effects of some problems, particularly not
>> corruption
On Thu, Aug 27, 2009 at 10:38 AM, Greg Stark wrote:
>
> What I've been thinking of doing is having the regression suite take a
> backup after initdb and set archive mode on. when the regression suite
> finishes start the backup up and replay all the WAL.
>
> I'm not sure how to compare the database
On Thu, Aug 27, 2009 at 11:29 AM, Tom Lane wrote:
> Robert Haas writes:
>> Well, I wasn't suggesting adding a lot more testing of things that
>> we're already testing. I was assuming that we would craft the
>> additional tests to hit areas that we are not now covering well. My
>> point here is o
On Thu, Aug 27, 2009 at 11:29:42AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > Well, I wasn't suggesting adding a lot more testing of things that
> > we're already testing. I was assuming that we would craft the
> > additional tests to hit areas that we are not now covering well. My
> > poi
On Thu, Aug 27, 2009 at 3:11 PM, Tom Lane wrote:
>
> Precisely...
>
> What I'd like to see is some sort of test mechanism for WAL recovery.
> What I've done sometimes in the past (and recently had to fix the tests
> to re-enable) is to kill -9 a backend immediately after running the
> regression te
Robert Haas writes:
> Well, I wasn't suggesting adding a lot more testing of things that
> we're already testing. I was assuming that we would craft the
> additional tests to hit areas that we are not now covering well. My
> point here is only to what Peter said upthread: we want to be able to
>
On Thu, Aug 27, 2009 at 10:11 AM, Tom Lane wrote:
> Robert Haas writes:
>> ... That sounds a lot like the definition of a
>> regression test suite. Of course, we have that already, but it's
>> nowhere near comprehensive. Maybe we should be looking at an expanded
>> test suite that runs on a time
Robert Haas writes:
> ... That sounds a lot like the definition of a
> regression test suite. Of course, we have that already, but it's
> nowhere near comprehensive. Maybe we should be looking at an expanded
> test suite that runs on a time scale of hours rather than seconds.
mysql's got one of
Robert Haas wrote:
> Maybe we should be looking at an expanded test suite that runs on a
> time scale of hours rather than seconds.
> if we could say that we had a regression test suite which covered X%
> of our code, and it passed on all Y platforms tested, that would
> certainly be a confide
On Wed, Aug 26, 2009 at 7:39 PM, Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> Much of the delay and uncertainty during beta in my mind comes from the
>> situation that we wait for negative results and don't trust the release
>> until we have seen and fixed enough of them. Instead of waiting f
On Thu, Aug 27, 2009 at 2:30 AM, Stephen Frost wrote:
> I agree entirely with Andrew here- what we need are a set of users who
> would be willing to run their actual applications against a beta release
> in a testing environment. The Beta-Mom position would be working with
> some list of users who
Tom Lane wrote:
> Josh Berkus writes:
>>> That is a slightly alarmist. Who are we going to lose these users to?
>
>> Drizzle. MySQL forks. CouchDB. Any database which has replication
>> which you don't need a professional DBA to understand. Whether or not
>> it works.
>
> You haven't explai
* Andrew Dunstan (and...@dunslane.net) wrote:
> Actually, what I had in mind was getting people to run their
> applications etc. in some non-production environment on the beta. I
> talked to a client today and he said "sure, we have several development
> environments and we can put one or two
On Aug 26, 2009, at 8:17 AM, Jean-Michel Pouré wrote:
Le mercredi 26 août 2009 à 01:36 -0600, Rick Gigger a écrit :
One possible reason that replication is more critical now than it
was
a year ago is the rise in cloud computing. The ability to fire up
instances on demand is much more useful w
Peter Eisentraut wrote:
> Much of the delay and uncertainty during beta in my mind comes from the
> situation that we wait for negative results and don't trust the release
> until we have seen and fixed enough of them. Instead of waiting for
> concrete, positive results and producing the release w
On ons, 2009-08-26 at 18:15 -0400, Tom Lane wrote:
> > I think there is a lot of merit (as Andrew suggests) in running a
> > production application on a beta version of the database just to see
> > if anything funny happens.
>
> ... but here we seem to be coming out at the same place anyway. Gett
On Thu, Aug 27, 2009 at 12:03 AM, Dimitri
Fontaine wrote:
> Is the offering good enough? We might need to run some kind of tutorials
> for users to be able to run large tests easily, and maybe think about
> some newer tools allowing to compare logs of two application runs in two
> database versions
On Wed, Aug 26, 2009 at 11:15 PM, Tom Lane wrote:
> ... but here we seem to be coming out at the same place anyway. Getting
> people to put their existing apps onto a beta is very productive.
> We have to encourage people to do more of that while it's still beta,
> instead of waiting till .0 or .1
Robert Haas writes:
> On Wed, Aug 26, 2009 at 5:12 PM, Peter Eisentraut wrote:
>> ... Surely it's been tested before, else it would not be in
>> the release, right?
> I would sure hope so. Testing features individually makes a whole lot
> more sense to me than testing the release as a whole. Ju
Hi,
Peter Eisentraut writes:
> On ons, 2009-08-26 at 14:26 -0400, Robert Haas wrote:
>> Sure, but an aimless mandate to do testing for 4 (or 8, or 12) months
>> doesn't necessarily buy you much, either. I'm good at focused
>> activity - but there was nothing focused about 8.4 beta that I could
>
On Wed, Aug 26, 2009 at 5:12 PM, Peter Eisentraut wrote:
> On ons, 2009-08-26 at 14:26 -0400, Robert Haas wrote:
>> Sure, but an aimless mandate to do testing for 4 (or 8, or 12) months
>> doesn't necessarily buy you much, either. I'm good at focused
>> activity - but there was nothing focused abo
Josh Berkus wrote:
Tom, all,
As far as the alpha releases go, I wouldn't --- I see no evidence that
we have the manpower to formalize them any more than they are now.
I do like the idea of trying to reach out to more beta testers and
manage that phase more aggressively. Maybe if we can ma
Tom, all,
> As far as the alpha releases go, I wouldn't --- I see no evidence that
> we have the manpower to formalize them any more than they are now.
> I do like the idea of trying to reach out to more beta testers and
> manage that phase more aggressively. Maybe if we can make something
> happ
On ons, 2009-08-26 at 14:26 -0400, Robert Haas wrote:
> Sure, but an aimless mandate to do testing for 4 (or 8, or 12) months
> doesn't necessarily buy you much, either. I'm good at focused
> activity - but there was nothing focused about 8.4 beta that I could
> see. Maybe we need some kind of Te
David Fetter writes:
> On Wed, Aug 26, 2009 at 02:46:43PM -0400, Tom Lane wrote:
>> The alpha releases as currently constituted are practically the
>> exact opposite of what's being suggested here :-(. We are pushing
>> them out without very much advertisement, and certainly without any
>> formal
On Wed, Aug 26, 2009 at 02:46:43PM -0400, Tom Lane wrote:
> "Matthew T. O'Connor" writes:
> > Alvaro Herrera wrote:
> >> This seems a good idea. Possibly pushing the betas more
> >> aggresively to current users would make them tested not only by
> >> PG hackers ...
>
> > Isn't this the purpose o
2009/8/26 Jean-Michel Pouré :
> Dear Kevin
>
>> So when you talk about focusing on usablility improvements you mean
>> that priority should be given to supporting MySQL-specific syntax
>> extensions and ensuring that there are no queries where the MySQL
>> optimizer comes up with a more efficient p
"Matthew T. O'Connor" writes:
> Alvaro Herrera wrote:
>> This seems a good idea. Possibly pushing the betas more aggresively to
>> current users would make them tested not only by PG hackers ...
> Isn't this the purpose of the new alpha releases, at lease to some extent.
The alpha releases as c
Alvaro Herrera wrote:
This seems a good idea. Possibly pushing the betas more aggresively to
current users would make them tested not only by PG hackers ...
Isn't this the purpose of the new alpha releases, at lease to some extent.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
Dear Kevin
> So when you talk about focusing on usablility improvements you mean
> that priority should be given to supporting MySQL-specific syntax
> extensions and ensuring that there are no queries where the MySQL
> optimizer comes up with a more efficient plan than PostgreSQL?
Yes. PostgreSQL
On Wed, Aug 26, 2009 at 1:01 PM, Tom Lane wrote:
> Yup. This is a huge problem and we need to deal with it somehow. At
> the same time, I'm worried that our beta testing process is already
> inadequate. We've found several rather embarrassing bugs in 8.4, for
> instance, things that should have
Andrew Dunstan wrote:
> Perhaps some more formalised beta program would be useful. I have
> at least one client who could probably be persuaded to devote some
> resources to Beta testing. Maybe we need a Beta Program co-ordinator
> or some such animal. I suspect that plenty of possible beta tes
Andrew Dunstan escribió:
> Perhaps some more formalised beta program would be useful. I have at
> least one client who could probably be persuaded to devote some
> resources to Beta testing. Maybe we need a Beta Program co-ordinator
> or some such animal. I suspect that plenty of possible beta tes
Tom Lane wrote:
Andrew Dunstan writes:
My concern is not just with those features, but with the whole ratio of
the window for new work to the total development cycle. That ratio keeps
going down and the time the tree is effectively frozen to new features
keeps going up.
Yup. This
> Robert Haas wrote:
>> I am assuming that at least Hot Standby and Streaming Replication will
>> likely require two CommitFests to go from the point where they are
>> seriously reviewable to actual commit.
FWIW, I think that both HS and SR are special cases: if we ever see
reviewable patches for
Andrew Dunstan wrote:
> the window for new work to the total development cycle. That ratio
> keeps going down and the time the tree is effectively frozen to new
> features keeps going up. I'd like to see us keep the tree open as
> long as possible but be much more ruthless about chopping off thi
On Wed, Aug 26, 2009 at 12:07 PM, Andrew Dunstan wrote:
> Robert Haas wrote:
>>
>> I am assuming that at least Hot Standby and Streaming Replication will
>> likely require two CommitFests to go from the point where they are
>> seriously reviewable to actual commit. So if they hit the 9/15 date,
>>
Robert Haas wrote:
I am assuming that at least Hot Standby and Streaming Replication will
likely require two CommitFests to go from the point where they are
seriously reviewable to actual commit. So if they hit the 9/15 date,
they should make 8.5 even with just three CommitFests. If they don'
Jean-Michel Pouré wrote:
> Kevin Grittner a écrit :
>> It's not clear to me what you feel is needed.
> http://drupal.org/node/559302
These look like performance issues.
> http://drupal.org/node/14
These are MySQL compatibility issues.
So when you talk about focusing on usablility impr
On Aug 26, 2009, at 11:18 , Jean-Michel Pouré wrote:
Web apps are 95% of PostgreSQL possible users.
Where does this figure come from?
Michael Glaesemann
grzm seespotcode net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
Jean-Michel Pouré wrote:
Everytime I try a new Drupal module under PostgreSQL, I run into tiny
SQL problems ranging from error to performance drop. The most
problematic problem is http://drupal.org/node/559986
I strongly suspect this post badly mis-diagnoses the problem.
IMHO for what
Le mercredi 26 août 2009 à 09:30 -0500, Kevin Grittner a écrit :
> It's not clear to me what you feel is needed. That could mean many
> things
Dear Kevin,
I rarely post on Hackers, so I will try to explain:
* I use PostgreSQL since 1998.
* I took part in the development of pgAdmin 1&2.
* I l
Jean-Michel Pouré wrote:
> focus on usability.
It's not clear to me what you feel is needed. That could mean many
things
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
1 - 100 of 123 matches
Mail list logo
