Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)

From: teg(at)redhat(dot)com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=)
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, The Hermit Hacker <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Date: 2000-10-27 18:54:54
Message-ID: xuyhf5yunb5.fsf@hoser.devel.redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-ports

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Trond Eivind =?iso-8859-1?q?Glomsr=F8d?= 2000-10-27 18:57:39 Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Previous Message Neil Davis 2000-10-27 18:21:27 Selects in server side functions

Browse pgsql-hackers by date

  From Date Subject
Next Message Trond Eivind =?iso-8859-1?q?Glomsr=F8d?= 2000-10-27 18:57:39 Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Previous Message Ross J. Reedstrom 2000-10-27 17:41:50 Re: Re: [COMMITTERS] pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)

Browse pgsql-ports by date

  From Date Subject
Next Message Trond Eivind =?iso-8859-1?q?Glomsr=F8d?= 2000-10-27 18:57:39 Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Previous Message Bruce Momjian 2000-10-27 17:05:16 Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)