Re: Upgrading rant. - Mailing list pgsql-hackers

From Lamar Owen
Subject Re: Upgrading rant.
Date
Msg-id 200301031516.34384.lamar.owen@wgcr.org
Whole thread Raw
In response to Re: Upgrading rant.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Upgrading rant.
List pgsql-hackers
On Thursday 02 January 2003 19:26, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > So I figured I'd roll a 7.1.3 RPMset for him to install onto Red Hat 8. 
> > It was very bad.  It simply would not build -- I guess it's the gcc 3
> > stuff.

> If you don't know *exactly* why it doesn't build, I don't think you
> should be blaming us for it.

Who did I blame?  (no one).  I just made a statement -- which you pretty much 
agreed with later (gcc --version being multiline IS a gcc 3 problem, no? 
:-)). No blame at all.  None of the message was a blame game of any kind, 
although you seem to take it personally every time I bring up upgrading.  
But, then again, I take it personally when someone e-mails me ranting (and 
sometimes cussing) about my stupid program's not upgrading (and PostgreSQL 
isn't 'my' program!).

> > THIS DOESN'T HAPPEN WITH MySQL.

> Oh?  Do they have a crystal ball that lets them predict incompatible
> future platform changes?

No, they just allow for the old format, while making a new format.  At least 
that's the way it looks from reading the docs and a cursory install run.  The 
Linux Magazine article states it in a quite pointed way -- I'll grab that 
magazine when I get back home and post a quote if you'd like.

> (I'm not very sure I believe your assertion above, anyway.  We are
> painfully aware of our own compatibility issues, but I wonder how many
> people on this list pay close enough attention to MySQL to know what
> their version-to-version compatibility track record *really* is.)

I pay close enough attention that I was asked by a publisher to do a technical 
review of a MySQL reference book.

> > And I'd love to see someone who has the time to do so (not me) grab
> > this bull by the horns and make it happen.

> Well, this is exactly the issue: someone would have to put substantial
> amounts of time into update mechanisms and/or maintenance of obsolete
> versions, as opposed to features, performance improvements, or bug
> fixes.

Fixing the upgrade 'bug' is a bugfix, IMHO.  A _big_ bugfix.

> Personally, I feel that if we weren't working as hard as we could on
> features/performance/bugfixes, the upgrade issue would be moot because
> there wouldn't *be* any reason to upgrade.

However, I'm sure there are people who hesitate to upgrade BECAUSE of the 
difficulty, thereby causing them to miss features.  And potentially bugfixes, 
too.

>  So I'm not planning to
> redirect my priorities.  But this is an open source project and every
> developer gets to set their own priorities.  If you can persuade someone
> to put their time into that, go for it.

Which is why I shake the branches periodically, to see if I can persuade 
someone who can do this (in practice this means they either have a great deal 
of free time, or they are paid fulltime to work on PostgreSQL).

> I think you're wasting your time trying to hold us to a higher standard
> of backwards-compatibility than is maintained by the OSes and tools we
> must sit on top of.

I think PostgreSQL already sets a higher standard in many ways.  Particularly 
in the release cycle (we don't 'release early and release often').
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11



pgsql-hackers by date:

Previous
From: mlw
Date:
Subject: Re: Upgrading rant.
Next
From: Tom Lane
Date:
Subject: Re: python interface