Mega-commits to "stable" version

Is anyone else disturbed by wholesale changes to what is supposed to
be a stable release?
I am sure Marc will say these are low-risk changes --- but they're not
*no* risk, because there is always a chance of propagating part of
some other change that you didn't want, or failing to propagate all
of the change you did want. And how much testing will the modified
6.5.x code get before it gets published as a stable version?

I agree, and think we should back off on some of those patches, or at
least back off of applying patches of that nature in the future. I'm
guessing that it wasn't clear to Marc what the range of opinions might
be on these particular patches.

otoh, since it's a done deal, it should encourage us to do a bit more
testing than we would have otherwise, on a wider range of platforms.
And the changes probably got the camel's nose under the tent to move
forward with 64-bit fixes on the stable branch (which would be nice
for our RPM work).

Perhaps the Japanese contingent, who seem to have a remarkable range
of platforms, will be willing and able to regression test when we get
closer to a v6.5.2.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

Note that I have no problems with someone requesting a patch to be backed
out...IMHO, anything dealing with the configuration process should be
brought back into -STABLE (ie. the CPU changes that Bruce did)...but
anything else that I've changed, or will change, are generally what I
consider to be "safe bets"...if I'm wrong, they are easy to back
out...just let me know...

On Tue, 3 Aug 1999, Tom Lane wrote:

"Marc G. Fournier" <scrappy> writes:

Another 'mega-commit' of back-patches ...

- - integrating the #include file cleanup that Bruce recently did
- - got the CPU change to adt/Makefile
- - changing DOUBLEALIGN -> MAXALIGN

Is anyone else disturbed by wholesale changes to what is supposed to
be a stable release?

I am sure Marc will say these are low-risk changes --- but they're not
*no* risk, because there is always a chance of propagating part of
some other change that you didn't want, or failing to propagate all
of the change you did want. And how much testing will the modified
6.5.x code get before it gets published as a stable version?

My feeling is that we should only back-patch essential bug fixes.
You can define "essential" as "anything a user requests", if you like.
But surely code cleanups do not qualify unless they fix a demonstrable
bug.

Just my $0.02...

regards, tom lane

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

Thomas Lockhart wrote:

Is anyone else disturbed by wholesale changes to what is supposed to
be a stable release?
I am sure Marc will say these are low-risk changes --- but they're not
*no* risk, because there is always a chance of propagating part of
some other change that you didn't want, or failing to propagate all
of the change you did want. And how much testing will the modified
6.5.x code get before it gets published as a stable version?

Maybe we should do a 6.5.2beta before the real 6.5.2 so that people are
warned and know what to expect?

------------
Hannu

On Tue, 3 Aug 1999, Hannu Krosing wrote:

Thomas Lockhart wrote:

Is anyone else disturbed by wholesale changes to what is supposed to
be a stable release?
I am sure Marc will say these are low-risk changes --- but they're not
*no* risk, because there is always a chance of propagating part of
some other change that you didn't want, or failing to propagate all
of the change you did want. And how much testing will the modified
6.5.x code get before it gets published as a stable version?

Maybe we should do a 6.5.2beta before the real 6.5.2 so that people are
warned and know what to expect?

Should always have at least a 1 week beta before a minor-minor release,
no?

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org