Re: fixing REL7_3_STABLE build issues - Mailing list pgsql-patches

From Tom Lane
Subject Re: fixing REL7_3_STABLE build issues
Date
Msg-id 1405.1121530281@sss.pgh.pa.us
Whole thread Raw
In response to Re: fixing REL7_3_STABLE build issues  (Kris Jurka <books@ejurka.com>)
List pgsql-patches
Kris Jurka <books@ejurka.com> writes:
> On Sat, 16 Jul 2005, Tom Lane wrote:
>> I'd like to have a more principled approach to fixing the back branches
>> than "we'll do whatever it takes to have a clean buildfarm board on the
>> set of machines that happen to have volunteered to run buildfarm on that
>> branch".

> I think the emphasis on the buildfarm (at least for the "principled
> approach") is wrong.  The policy should be that for any platform  all
> supported branches should pass all tests unless something is legitimately
> broken and cannot be fixed without major surgery.

I am suggesting that the pre-7.4 geometry test *is* broken, and that
fixing it only for those machines that join the buildfarm is (a)
wrongheaded and (b) a waste of effort.  It'll still be broken on an
unknown (but ever-growing due to changes in toolchains) population of
allegedly-supported platforms that happen not to be represented in the
buildfarm.

I agree that fixing compile problems is a worthwhile activity (and
you'll note I applied that part of Andrew's patch).  I don't agree that
fixing known-problematic regression tests is a good use of time.  We
are not going to learn anything new by keeping geometry enabled in the
back branches, so why not cut our losses?

If you don't like removing it altogether, how about marking it "ignore"
as we do for the "random" test, so that failures are treated as
noncritical?

            regards, tom lane

pgsql-patches by date:

Previous
From: Kris Jurka
Date:
Subject: Re: fixing REL7_3_STABLE build issues
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved