On 10/4/18 9:34 AM, Victor Stinner wrote: > Hi, > > 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. Michael explicitly said this is a personal effort. IBM or other big money is not involved. Is paying the best way to get features into Python? Does becoming a core dev mean you can now get paid for approving changes? Some of the implications are quite disturbing :( > Le mercredi 3 octobre 2018, Michael Felt <aixtools at felt.demon.nl > <mailto: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 > >>> 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. > >> > >> > >> > >> > > > > _______________________________________________ > > Python-Dev mailing list > > Python-Dev at python.org <mailto:Python-Dev at python.org> > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/encukou%40gmail.com >
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