Skip site navigation (1) Skip section navigation (2)

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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
Cc: Trond Eivind Glomsrød <teg(at)redhat(dot)com>, 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 17:05:16
Message-ID: 200010271705.NAA07041@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackerspgsql-ports
> > What would be good is for someone to constructively make a posting about
> > the known problems, and come up with acceptable solutions.  Asking us to
> > fix it really isn't going to help because we don't deal with RPM's here,
> > and we don't have enough free time to make significant changes to meet
> > the needs of RPM's.
> 
> Which is why I stepped up to the plate last year to help with RPM's.
> 
> I apologize if you took my post (which I edited greatly) as 'venting' --
> it was not my intention to 'vent', much less offend.  I just want to
> know what to expect from the 7.1 release.  I feel that that is germane
> to the Hackers list, as the knowledge necessary to answer the question
> is to be found on the list. (and you answered the question above).

No, I was not pointing to you when I mentioned venting.  There have been
other RPM threads lately.  I just want information on how to make things
better for RPM's, not vents.

> Like it or not, in the eyes of many people having solid RPM's is a core
> issue.  If there are gotchas, I want to document them so people don't
> get blindsided.  Or work around them.  Or ask why the change is
> necessary in the first place.

Sure.

> I appreciate the fact that we are not here to make it easy for
> distributors to package our software.  I also appreciate the fact that
> if you don't at least make an effort to work with major distributors
> (and RedHat, TurboLinux, Caldera, and SuSE together comprise a major
> userbase) that you run the risk of not being distributed in favor of an
> inferior product.

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.

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 also appreciate and applaud the cross-platform mentality of the
> PostgreSQL developers.  Linux is far from the only OS to be supported by
> PostgreSQL, true.  But Linux is also the most popular OS for PostgreSQL
> deployment.

True, it is the most popular, but that doesn't make the others less
important. 

This whole statement comes across as, "You run on Linux, and look, you
took the time to run on other OS's too.  How quaint."

In the history of this project, Linux was an after-thought.  None of our
platforms are inferior or superior, except to the extent that the
platform does not support Unix standard functions (like NT/Cygwin).

> However, there are known problems that can bite people who are not using
> RPM's and are not running Linux.  Some of those problems are such that
> it will take someone with more knowledge than I currently possess to
> solve.  One is the issue of upgrading/migrating tools.  This is not an
> RPM-specific issue.  To me, that is the only big issue that I have
> spoken about in a way that could even remotely be construed as
> 'venting'.  And it is not a Linux-specific issue.  It is a core issue.

Again, your comments where quite helpful.  We need more of them.  We
need to hear more about the problems people are having with RPM's, and
how to make them better.

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.  My bet is that some middle layer
can be created that will fix that for us.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

Responses

pgsql-ports by date

Next:From: Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=Date: 2000-10-27 18:54:54
Subject: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Previous:From: Lamar OwenDate: 2000-10-27 16:34:12
Subject: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)

pgsql-hackers by date

Next:From: Ross J. ReedstromDate: 2000-10-27 17:41:50
Subject: Re: Re: [COMMITTERS] pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)
Previous:From: The Hermit HackerDate: 2000-10-27 16:40:51
Subject: Mailing List Slowdowns ...

pgsql-general by date

Next:From: Neil DavisDate: 2000-10-27 18:21:27
Subject: Selects in server side functions
Previous:From: Steve WolfeDate: 2000-10-27 16:37:44
Subject: Re: Postgres 7.0.2-2 on Red Hat 7.0?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group