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 test_aix.py might be a good idea for >>> aix-only tests > > I may be wrong on this. > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/aixtools%40felt.demon.nl
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
