[Python-Dev] dear core-devs
aixtools at felt.demon.nl
Wed Oct 3 12:57:00 EDT 2018
On 10/3/2018 2:48 AM, Terry Reedy wrote:
> On 10/2/2018 7:16 PM, Michael Felt wrote:
>> On 10/2/2018 11:34 PM, Terry Reedy wrote:
>>> On 10/2/2018 12:41 PM, Simon Cross wrote:
>>>> Are there any core devs that Michael or Erik could collaborate with?
>>>> Rather than rely on adhoc patch review from random core developers.
>>> You two might collaborate with each other to the extent of reviewing
>>> some of each other's PRs.
>> Might be difficult. We both, or at least I, claim ignorance of the
>> others platform.
> Partial reviews, short of accept/change are better than no review and
> can make a merge decision easier for a core dev. You should each be
> or become familiar with PEP 7 and somewhat familiar with local C
> idioms. Do names follow local standards. Do C-API calls make sense.
Sounds simple enough. The tricky part is "the details".
> >> I still have a lot of PEP to learn, and my idea of a
> >> bug-fix (for Python2) was seen by core-dev as a feature change.
> Failures of current tests would seem to me to be bugs. However, some
> bug fixes require a feature change. It is an awkward situation. We
> are increasingly reluctant to patch 2.7.
Some are quite simple to fix, even if hard to find: such as:
"elif cmd is None:" -> "elif notcmd orcmd is None:"
Some are not bugs at all - very hard to find! Instead, "textual"
differences because a library is overly optimized - the expected
exception occurs - but no error message. Linking with a less optimized
(libssl.a and libcrypto.a) resolved many reported test "failures".
Nearly three years ago I was keen to see things in Python2(.7), but not
so much now. I also feel the time is to push hard towards current
>>> That still leaves the issue of merging.
>> How much confidence is there in all the "CI" tests? Does that not offer
>> sufficient confidence for a core-dev to press merge.
> Code for new features or bugs that escaped the tests should have new
> tests. AIX-specific code should (as in must ;-) be tested before
> being submitted, since it will not be properly tested by CI. With CI
> now covering Windows twice, Linux twice, and Mac, I believe it has
> become rarer for buildbots to fail after CI passes. Victor would know.
> I believe that you are initially dealing with bugs that do not pass
> current tests.
I am dealing with tests that do not pass. The dilemma: what is wrong -
the test, or what it is testing? Generally speaking, I cannot call
Python3 (master) broken. So I look for a "root cause" in a test
assumption that is wrong, and find a way to correct that.
Sometimes, it is a bit of both - and those are very hard to resolve
See the discussion, elsewhere, regarding MACADDR. It has never been that
platform Y does not have a MACADDR - rather, platform Y formats it
differently than (all) other platforms.
>> How about "master" continuing to be what it is, but insert a new
>> "pre-master" branch that the buildbots actually test on (e.g., what is
>> now the 3.X) and have a 3.8 buildbot - for what is now the "master".
>> PR would still be done based on master, but an "initial" merge would be
>> via the pre-master aka 3.X buildbot tests.
>> How "friendly" git is - that it not become such a workload to keep it
>> clean - I cannot say. Still learning to use git. Better, but still do
>> not want to assume it would be easy.
> Too complicated.
>> My hope is that it would make it easier to consider a "merge" step that
>> gets all the buildbots involved for even broader CI tests.
> I considered the wider buildbot fleet to be post-merge CI ;-).
>>> I think for tests, a separate test_aix.py might be a good idea for
>>> aix-only tests
> I may be wrong on this.
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev