[Python-Dev] dear core-devs

Terry Reedy tjreedy at udel.edu
Tue Oct 2 20:48:11 EDT 2018


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.



More information about the Python-Dev mailing list