pandas -- I think we should drop BE platforms

[Yaroslav Halchenko]

Hi The Team,

"Maintaining" pandas builds on big endians (and some others, but let's
concentrate on BE for now) was always problematic. Upstream does not
support them and I am somewhat tired of pestering them with failures on
them. Only once or twice test failures on those platforms pointed
to genuine bugs (iirc in numpy or scipy) which just were not revealed on
x86.

Selectively skipping the tests on those platforms is just hiding the
bugs away and pretending that it is all working correctly AFAIK. The
worst thing which I think we could do to the users on those platforms
(if there are any) is to make their results knowingly incorrect,
while no alarm is raised.

As to me, the most logical step would be to stop pretending to support
BE builds for pandas and drop support of all big endian builds
altogether.

1. remove all patches which disable tests on big endians (I would have
even patched to remove upstream skips on those archs, so we do not fall
into the trap of missing smth)

2. Please correct me if I am wrong, but I do not think that there
is some flag to say smth like

Architecture: any [!big-endian]

so we would need to unlist them explicitly

Architecture: any [!s390x, !powerpc, !mips]

(or powerpc is not BE?)

Let me know what you think and either I have missed anything. If
someone wants to step up and jump into maintaining on BEs, please do so
now. If not, I will proceed as planned above.

[Sébastien Villemot]

Post by Yaroslav Halchenko
1. remove all patches which disable tests on big endians (I would have
even patched to remove upstream skips on those archs, so we do not fall
into the trap of missing smth)

I agree with that.

Post by Yaroslav Halchenko
2. Please correct me if I am wrong, but I do not think that there
is some flag to say smth like
Architecture: any [!big-endian]
so we would need to unlist them explicitly
Architecture: any [!s390x, !powerpc, !mips]
(or powerpc is not BE?)

No, leave "Architecture: any". Then the builds will fail on those arches. This
is what porters generally prefer, because they have a clear information about
what is wrong with the package on their arch (and possibly they can act and
send patches).