On 2/22/21, 1:39 PM, "Steve Dower" <steve.do...@python.org> wrote:
On 2/22/2021 5:18 PM, Matthias Klose wrote:
> On 2/21/21 1:13 PM, Victor Stinner wrote:
> Document what is supported, be inclusive about anything else. Don't make
a
> distinction yet between legacy and upcoming new architectures.
I agree with this, and I don't see any reason why we shouldn't just use
the list of stable buildbot platforms as the "supported" list. That
makes it really clear what the path is to push support onto upstream
(join up and bring a buildbot with you), and also means that we've got a
physically restricted set of machines to prove work before doing a release.
Actively blocking anything at all seems unnecessary at the source/build
level. That's for pre-built binaries and other conveniences.
Cheers,
Steve
_______________________________________________
+1 to this.
I use a few unsupported platforms, not as a hobby, but in my work. I generally
don't require ALL the things in python to work on these platforms, so even if I
were to contribute a buildbot for an obscure (but definitely not "hobby")
platform, it's implied that I would also need to fix test failures in modules I
don't use. I generally need to provide some reason for me to use my employer's
time, so I can't really justify fixing test failures in code the company
doesn't use.
I think these users are just asking that what currently works not be broken
intentionally, and that follows the spirit of Autoconf, to test if something
works and enable if it when it does.
There are also other ways to reduce the burden of maintaining a large number of
platforms, such as abstracting away the OS services.
The other thing that crept into this thread was the mention of test that
intermittently fail.
That's a huge problem because it suggests that applications will sometimes fail.
I have usually seen these sort of issues because of
1) Uninitialized memory being used (read)
2) Threading problems
3) Resources used (files, networking, daemons) but unavailable
4) memory mis-management (buffer overrun that doesn't cause a crash)
#3 is probably best fixed by testing for resources and skipping when unavailable
The others are problems in the code, and can be fixed with clang sanitizers, but
Without some routine running of them, those sorts of problems will reappear.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/6VCZYPSIB4QE3FL4L3D2WER3VU3LZGCO/
Code of Conduct: http://python.org/psf/codeofconduct/
