On Thu, Aug 27, 2009 at 12:03:05AM +0200, Dimitri Fontaine wrote:
Hi,
Peter Eisentraut pete...@gmx.net 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
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 has been
Bruce Momjian br...@momjian.us 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
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 to
On Mon, Aug 31, 2009 at 1:57 PM, Bruce Momjianbr...@momjian.us 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
Kevin Grittner wrote:
Bruce Momjian br...@momjian.us 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,
Robert Haas wrote:
On Mon, Aug 31, 2009 at 1:57 PM, Bruce Momjianbr...@momjian.us 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
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 good
On Mon, Aug 31, 2009 at 1:59 PM, Bruce Momjianbr...@momjian.us wrote:
Robert Haas wrote:
On Mon, Aug 31, 2009 at 1:57 PM, Bruce Momjianbr...@momjian.us 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
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 Momjianbr...@momjian.us 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
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 by
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
doing
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 Momjianbr...@momjian.us wrote:
Josh Berkus wrote:
Per the above, it would not. ?It would make things worse. ?This has
been
true at every
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 find that some
On Mon, Aug 31, 2009 at 2:20 PM, Bruce Momjianbr...@momjian.us 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
Bruce Momjian br...@momjian.us 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
Bruce Momjian br...@momjian.us 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?
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 a
Kevin Grittner wrote:
Bruce Momjian br...@momjian.us 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
Kevin Grittner wrote:
Bruce Momjian br...@momjian.us 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
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
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 patch
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
know
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 to change with
On Sat, Aug 29, 2009 at 1:05 PM, Bruce Momjianbr...@momjian.us 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
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
Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Robert Haas robertmh...@gmail.com 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
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 the
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
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
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-users
On Fri, Aug 28, 2009 at 7:35 AM, Greg Smithgsm...@gregsmith.com 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.
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 have a
Ron Mayer rm...@cheapcomplexdevices.com 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
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.
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 for
On Wed, Aug 26, 2009 at 7:39 PM, Bruce Momjianbr...@momjian.us 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
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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.
On Thu, Aug 27, 2009 at 10:11 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On Thu, Aug 27, 2009 at 3:11 PM, Tom Lanet...@sss.pgh.pa.us 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
On Thu, Aug 27, 2009 at 11:29:42AM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
On Thu, Aug 27, 2009 at 11:29 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Thu, Aug 27, 2009 at 10:38 AM, Greg Starkgsst...@mit.edu 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
Greg Stark gsst...@mit.edu writes:
On Thu, Aug 27, 2009 at 3:11 PM, Tom Lanet...@sss.pgh.pa.us 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,
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 sounds
On Thu, Aug 27, 2009 at 2:54 PM, Peter Eisentrautpete...@gmx.net 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
Hi,
Robert Haas robertmh...@gmail.com writes:
On Thu, Aug 27, 2009 at 2:54 PM, Peter Eisentrautpete...@gmx.net 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
On Sun, 2009-08-23 at 01:57 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
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 robertmh...@gmail.com 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.
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.
--
On Thu, Aug 27, 2009 at 3:53 PM, David Fetter da...@fetter.org 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
On Thu, Aug 27, 2009 at 3:56 PM, Alvaro
Herreraalvhe...@commandprompt.com 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?
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 04:22:58PM -0400, Jonah H. Harris wrote:
On Thu, Aug 27, 2009 at 3:53 PM, David Fetter da...@fetter.org 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.
Robert Haas robertmh...@gmail.com 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
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 for
Kevin Grittner escribió:
Robert Haas robertmh...@gmail.com 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Robert Haas robertmh...@gmail.com 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
On Thu, Aug 27, 2009 at 03:04:20PM -0400, Robert Haas wrote:
On Thu, Aug 27, 2009 at 2:54 PM, Peter Eisentrautpete...@gmx.net 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
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
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 keep
On Thu, Aug 27, 2009 at 6:09 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Robert Haas robertmh...@gmail.com wrote:
The final CommitFest began November 11, 2008. It closed March 25,
2009 (+ 144 days). Beta1 was released April 15, 2009 (+ 21 days).
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 top
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].
I
On Fri, Aug 28, 2009 at 4:39 AM, Ron Mayerrm...@cheapcomplexdevices.com 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
On Aug 24, 2009, at 9:46 PM, Robert Haas wrote:
On Mon, Aug 24, 2009 at 10:15 PM, David Fetterda...@fetter.org
wrote:
On Mon, Aug 24, 2009 at 08:02:31PM -0400, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
That is a slightly alarmist. Who are we going to lose these
users to?
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 when some of those boxes can
be database servers
Jean-Michel Pouréj...@poure.com 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:
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 12.
* I
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
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:
Jean-Michel Pouréj...@poure.com 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
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
On Wed, Aug 26, 2009 at 12:07 PM, Andrew Dunstanand...@dunslane.net 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
Andrew Dunstan and...@dunslane.net 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
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 them,
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
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
Andrew Dunstan and...@dunslane.net 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
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
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
Matthew T. O'Connor matt...@zeut.net 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
On Wed, Aug 26, 2009 at 1:01 PM, Tom Lanet...@sss.pgh.pa.us 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
2009/8/26 Jean-Michel Pouré j...@poure.com:
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
On Wed, Aug 26, 2009 at 02:46:43PM -0400, Tom Lane wrote:
Matthew T. O'Connor matt...@zeut.net 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
David Fetter da...@fetter.org 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
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
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
happen
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
On Wed, Aug 26, 2009 at 5:12 PM, Peter Eisentrautpete...@gmx.net 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
Hi,
Peter Eisentraut pete...@gmx.net 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Aug 26, 2009 at 5:12 PM, Peter Eisentrautpete...@gmx.net 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
On Wed, Aug 26, 2009 at 11:15 PM, Tom Lanet...@sss.pgh.pa.us 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
On Thu, Aug 27, 2009 at 12:03 AM, Dimitri
Fontainedfonta...@hi-media.com 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
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. Getting
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 with
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
* 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
1 - 100 of 123 matches
Mail list logo
