[Python-Dev] dear core-devs
vstinner at redhat.com
Thu Oct 4 03:34:56 EDT 2018
If IBM wants a better Python support, it would help a lot if IBM pays for
this development. With money, you can easily find core dev contractors.
Antoine Pitrou has been paid in the past to enhance Python support in
Solaris and it worked well.
Le mercredi 3 octobre 2018, Michael Felt <aixtools at felt.demon.nl> a écrit :
> 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
>> 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
> 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.
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev