[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