Peter Eisentraut wrote:
> Hannu Krosing writes:
> > It would be nice if someone (pgsql inc., great bridge, etc.) provided a
> > central web page for registering the results so that you won't need to
> > scan athe whole list to find out if your platform is already tested.
> "Platform already tested" is a misguided concept. Almost any machine is
> customized or deviating in some form or other. A listing of the form
> beta1 beta2 ...
> Linux ok ok
> Solaris ok broken
> ...
> is, IMHO, worse than useless, because it would actually decrease the
> amount of wide-spread, diverse testing.
It goes even further than that, of course -- there are different
versions to worry about. As a hypothetical, suppose for a moment that
PostgreSQL works fine on a Linux 2.2.17 box with glibc 2.1.3, but does
not work fine on Linux 2.4.1 with glibc 2.2 due to some undocumented
change to strncmp() (;-)). Currently, we're not that fine-grained --
while regression results are useful for ascertaining what is and isn't
supported, the regression results are very dependent on the environment
of the machine.
Any process that would discourage widespread testing is not good, IMHO.
Having a form by which you could register pass/fail/diffs for your
particular platform/environment could be good, with a blank slate each
release. But a blanket 'we support Linux' is, IMHO, not good -- _which_
Linux? 1.0? 1.2? 2.0? 2.0.38 but not 2.0.15? With libc 4 in a.out? Or
do you have to have ELF Libc 5? Libc 5.2.38 works, but 5.4.44 doesn't?
Glibc 2.0.5 but not 2.1.3? RedHat kernel 2.2.17 but not SuSE kernel
2.2.17? And, the worst: RedHat kernel 2.2.18 for RedHat 7 versus RedHat
kernel 2.2.18 for RedHat 6.2 (the kernel patches applied could in fact
be different enough to matter)?
These are all hypothetical examples, of course -- but Linux is not the
only platform that has these versioning problems just waiting to bite.
Linux probably has more of them than most, but it is not alone in having
them.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
