Robert Haas wrote:
On Sun, Jun 7, 2009 at 11:50 PM, Bruce Momjian<br...@momjian.us> wrote:
Stefan Kaltenbrunner wrote:
Josh Berkus wrote:
On 6/7/09 10:56 AM, Robert Haas wrote:
OK, that's more or less what I thought, and what I intended to convey
upthread. As far as core Postgres is concerned this is a new feature,
and we haven't worked out all the kinks yet.
Yes, I'm calling it "pg_migrator beta" in any advocacy/PR about it.
AFAIC, until we have these sorts of issues worked out, it's still a beta.
afaiks bruce stated he is going to remove the BETA tag from pg_migrator
soon so I guess calling it beta in the main project docs will confuse
the hell out of people(or causing them to think that it is not beta any
more).
So maybe calling it experimental(from the POV of the main project) or
something similar might still be the better solution.
This all sounds very discouraging. It is like, "Oh, my, there is a
migration tool and it might have bugs. How do we prevent people from
using it?"
Right now nothing in the project is referring to pg_migrator except in
the press release, and it is marked as beta there. How do you want to
deemphasize it more than that? Why did I bother working on this if the
community reaction is to try to figure out how to make people avoid
using it?
Because Rome wasn't built in a day.
indeed
It seems to me that you yourself placed a far more disparaging label
on it than anything that anyone has proposed today; this was a week
ago:
http://archives.postgresql.org/pgsql-hackers/2009-05/msg01470.php
well that is way more discouraging than what I wanted to say :)
I don't think it's anyone's intention to disparage your work on this
tool. It certainly isn't mine. But it seems obvious to me that it
has some pretty severe limitations and warts. The fact that those
limitations and warts are well-documented doesn't negate their
existence. I also don't think calling the software "beta" or
"experimental" is a way of deemphasizing it. I think it's a way of
being clear that this software is not the bullet-proof, rock-solid,
handles-all-cases-and-keeps-on-trucking level of robustness that
people have come to expect from PostgreSQL.
Exactly my point. pg_migrator gained a lot of momentum in the last weeks
an months, but imho it has still way to go. I do think that binary
upgrades are extremely important for us(that's why I did a fair amount
of testing on it) but I don't think that we should go too far for this
release.
A lot of the code that makes postgresql what it is now took years to
mature on pgfoundry or in contrib. So some of the questions to ask would be:
* is pg_migrator ready for contrib/? Probably not - it is still a way
too moving target so pgfoundry is good
* is pg_migrator ready for /src/bin?
Realistically I think we need to get at least one full cycle to see what
happens in the field with something as complex as pg_migrator to
really get a grasp on what else comes up.
FWIW, I have no problem at all with mentioning pg_migrator in the
release notes or the documentation; my failure to respond to your last
emails on this topic was due to being busy and having already spent
too much time responding to other emails, not due to thinking it was a
bad idea. I actually think it's a good idea. But I also think those
references should describe it as experimental, because I think it is.
I really hope it won't remain experimental forever, but I think that's
an accurate characterization of where it is now.
yep - I was not against mentioning it either. We just should do it in a
sane way(ie it is not part of the core project yet but endorsed and
might get added in the future or such) so we don't confuse people(like
we call it beta, the homepage does not) and yet get valuable feedback
which we certainly need to go forward.
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
