[Python-Dev] dear core-devs (original) (raw)

Michael Felt 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 Python3 versions.

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 without feedback.

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 testaix.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 https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/aixtools%40felt.demon.nl

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20181003/d41874dd/attachment.html>

More information about the Python-Dev mailing list