osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] dear core-devs



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. 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. I would
not feel comfortable trying to mentor someone in things PEP, etc..
> 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.
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.

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.

>
>> Michael and Eric: Question -- are you interested in becoming core
>> developers at least for the purposes of maintaining these platforms in
>> future?
>
> Since adhoc is not working to get merges, I had this same suggestion.
> Michael and Erik, I presume you have gotten some guidelines on what
> modifications to C code might be accepted, and what concerns people have.
imho: guidelines - paraphrased - as little as possible :)

I have many assumptions, and one of those is that my assumptions are
probably incorrect.
Goal: have AIX recognized as a Stable platform, even if not in the
highest supported category.
And that implies, support as far as I am able, to keep it "Stable".
>
> I think for tests, a separate test_aix.py might be a good idea for
> aix-only tests
Unclear to me how this would work. Too young in Python I guess (or just
a very old dog), but what test would be needed for AIX, or any other
platform, that would not need to be tested in some fashion for the
'other' platforms. At a hunch, where there are many platform.system()
dependencies expected (e.g., test_posix, maybe doing something in the
class definition (is there a "Root" Object/Class that all inherit from.
Maybe a (read-only) "root" attribute (or is property better?) could be
the value of platform.system(), and iirc, might be used by as @property
in unittest. (so, if not in "root" class, then in something like
unittest/__init__.py.

I hope to be "close" in "Python thinking" - enough that someone who
actually knows how the pieces fit together could come with a better, and
more appropriate guideline/implementation.

> , while modification of other tests might be limited to adding skips.?
> The idea would be to make it easy to remove aix stuff in the future if
> it again became unsupported.
IMHO: IBM and AIX do not mention it, but for openstack cloudmanagement
(very specifically cloud-init) AIX needs a recognized stable Python
implementation. I am "surprised" in the level of communication of IBM
with Python community.

Personally, I do not see AIX as a specialized platform. Feels more like
the "last-standing" fully supported (commercial OEM) 'POSIX-UNIX'. Of
course my focus is narrow - so maybe there is a lot of support for
commercial platforms such as HPUX, Solaris, and other mainstream UNIXes.
Feel free to correct me!!
> Ditto for other specialized platforms.
>
>
>
>