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. >> 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. >> 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. > 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4