Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Let them. It is their decision. Frankly, I have seen this attitude
> before, and I don't like it. Just the mention that "Gee, if you don't
> cooperate, we may yank you," is really a veiled threat. Now, I know you
> aren't saying that, but the "if you don't play nice, we will drop you"
> argument sounds a lot more like MS that a Linux vendor should be acting,
> especially since they are not telling us what they want or assisting in
> the work.
FWIW, I've never threatened to do so. If I wanted to, I would just do
it[1] - threats are bad and never cause anything but bad feelings.
That being said, my favorite wishes (in addition to as much SQL
compliance and performance as possible, of course) are:
* migration on upgrade
* old libraries being able to speak to newer databases, so old binaries can continue working after database upgrades
* good sonames on libraries - if a library hasn't changed, bumping the number to show it's part of a new version isn't
necesarry.If it is backwards compatible, just bump the minor version, if it isn't, bump the major version. Or even
better,use versioned symbols (I don't know how many other OSes than Linux and Solaris supports this, though).
As for assisting, at least Red Hat contributes to a lot of projects,
some of which are important to postgres on one or more platforms: gdb,
gcc, glibc and the linux kernel. There just isn't enough resources to
do everything, but I try to help out with the RPMs.
When we make patches for packages, we try to cooperate with the
author(s) to get them in - happily, we haven't had much of a need for
that with postgresql.
> The "We are big. Just fix it and let us know when it is ready" attitude
> does not work here, and that is what I am hearing mostly from the RPM
> people.
I haven't heard anyone say that.
> There must be a list of known problems. Let's hear them, so we can try
> to solve them as a group. However, in general, we do not make dramatic
> change to work around OS bugs, and do not plan to make major changes to
> work around the limitations of RPM's.
I don't think there are any apart from the upgrade issues - if library
versioning follows the standard, that certainly won't be a problem.
[1] which I'm not even close to doing - I've spent a bit of time lately
hunting down aliasing bugs in MySQL which causes wrong SQL query
results if compiled with "-O2". Ouch.
--
Trond Eivind Glomsrød
Red Hat, Inc.