[Python-Dev] Where is our official policy of what platforms we do support?
Over the past week or so there have been 2 patches to add support for various UNIX OSs. Now I thought we had stopped trying to add new esoteric OSs (e.g. I had never heard of MirOS until the patch for it came in), but I can't find a PEP that spells out what it takes to get a platform supported ( http://legacy.python.org/dev/peps/pep-0011/ is about removing platforms, not keeping them or adding them unless you are re-adding one which apparently just takes a volunteer). Do we want an official policy written down in a PEP (yes, I can write it)? Should I keep closing these patches and saying that we are not adding support for new operating systems and be hand-wavy about it? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where is our official policy of what platforms we do support?
On May 14, 2014, at 02:20 PM, Brett Cannon wrote: >Do we want an official policy written down in a PEP (yes, I can write it)? >Should I keep closing these patches and saying that we are not adding >support for new operating systems and be hand-wavy about it? Yes, I think a PEP describing both policy and implementation (i.e. which platforms we officially support) is worthwhile. While I think you could write a new PEP, I also think it might just make sense to co-opt PEP 11 and broaden its scope, since as you say, removing support is only half the story. Cheers, -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where is our official policy of what platforms we do support?
+1 for an official policy that comes with a "permanent maintainer for this platform required" as part of the list of requisites. js -><- On 14 May 2014 11:20, Brett Cannon wrote: > Over the past week or so there have been 2 patches to add support for > various UNIX OSs. Now I thought we had stopped trying to add new esoteric > OSs (e.g. I had never heard of MirOS until the patch for it came in), but I > can't find a PEP that spells out what it takes to get a platform supported > (http://legacy.python.org/dev/peps/pep-0011/ is about removing platforms, > not keeping them or adding them unless you are re-adding one which > apparently just takes a volunteer). > > Do we want an official policy written down in a PEP (yes, I can write it)? > Should I keep closing these patches and saying that we are not adding > support for new operating systems and be hand-wavy about it? > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where is our official policy of what platforms we do support?
On Wed, 14 May 2014 14:20:26 + Brett Cannon wrote: > Over the past week or so there have been 2 patches to add support for > various UNIX OSs. Now I thought we had stopped trying to add new esoteric > OSs (e.g. I had never heard of MirOS until the patch for it came in), but I > can't find a PEP that spells out what it takes to get a platform supported ( > http://legacy.python.org/dev/peps/pep-0011/ is about removing platforms, > not keeping them or adding them unless you are re-adding one which > apparently just takes a volunteer). OTOH you can fix a platform bug without officially supporting it. If someone files an OpenBSD-specific patch, it may make sense to commit it even without officially supporting OpenBSD. In practice it all depends on how intrusive / reasonable the patch is, and whether it is working around a platform-specific bug rather than a standards-compliant limitation. (we could call those "stochastically supported platforms" :-)) Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where is our official policy of what platforms we do support?
On Wed May 14 2014 at 10:43:18 AM, Antoine Pitrou wrote: > On Wed, 14 May 2014 14:20:26 + > Brett Cannon wrote: > > Over the past week or so there have been 2 patches to add support for > > various UNIX OSs. Now I thought we had stopped trying to add new esoteric > > OSs (e.g. I had never heard of MirOS until the patch for it came in), > but I > > can't find a PEP that spells out what it takes to get a platform > supported ( > > http://legacy.python.org/dev/peps/pep-0011/ is about removing platforms, > > not keeping them or adding them unless you are re-adding one which > > apparently just takes a volunteer). > > OTOH you can fix a platform bug without officially supporting it. If > someone files an OpenBSD-specific patch, it may make sense to commit it > even without officially supporting OpenBSD. In practice it all depends > on how intrusive / reasonable the patch is, and whether it is working > around a platform-specific bug rather than a standards-compliant > limitation. > > (we could call those "stochastically supported platforms" :-)) > Very true, but these patches are all for e.g. configure to recognize a specific platform by listing them in some constant. Changing code to be more general I have no issue with since that's just good practice. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where is our official policy of what platforms we do support?
On Wed, 14 May 2014 11:31:15 -0300, "Joao S. O. Bueno" wrote: > +1 for an official policy that comes with a "permanent maintainer for > this platform required" as part of the list > of requisites. > > js > -><- > > On 14 May 2014 11:20, Brett Cannon wrote: > > Over the past week or so there have been 2 patches to add support for > > various UNIX OSs. Now I thought we had stopped trying to add new esoteric > > OSs (e.g. I had never heard of MirOS until the patch for it came in), but I > > can't find a PEP that spells out what it takes to get a platform supported > > (http://legacy.python.org/dev/peps/pep-0011/ is about removing platforms, > > not keeping them or adding them unless you are re-adding one which > > apparently just takes a volunteer). > > > > Do we want an official policy written down in a PEP (yes, I can write it)? > > Should I keep closing these patches and saying that we are not adding > > support for new operating systems and be hand-wavy about it? In addition to a maintainer (who I think doesn't have to be a committer, though that would be ideal), I think a maintained buildbot should be a requirement for formal support. --David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where is our official policy of what platforms we do support?
On Wed May 14 2014 at 11:02:50 AM, R. David Murray wrote: > On Wed, 14 May 2014 11:31:15 -0300, "Joao S. O. Bueno" < > [email protected]> wrote: > > +1 for an official policy that comes with a "permanent maintainer for > > this platform required" as part of the list > > of requisites. > > > > js > > -><- > > > > On 14 May 2014 11:20, Brett Cannon wrote: > > > Over the past week or so there have been 2 patches to add support for > > > various UNIX OSs. Now I thought we had stopped trying to add new > esoteric > > > OSs (e.g. I had never heard of MirOS until the patch for it came in), > but I > > > can't find a PEP that spells out what it takes to get a platform > supported > > > (http://legacy.python.org/dev/peps/pep-0011/ is about removing > platforms, > > > not keeping them or adding them unless you are re-adding one which > > > apparently just takes a volunteer). > > > > > > Do we want an official policy written down in a PEP (yes, I can write > it)? > > > Should I keep closing these patches and saying that we are not adding > > > support for new operating systems and be hand-wavy about it? > > In addition to a maintainer (who I think doesn't have to be a committer, > though that would be ideal), I think a maintained buildbot should be a > requirement for formal support. > I would think someone how is/would be a core dev and a *stable* buildbot are requirements. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where is our official policy of what platforms we do support?
Am 14.05.2014 17:08, schrieb Brett Cannon: > On Wed May 14 2014 at 11:02:50 AM, R. David Murray > wrote: > >> On Wed, 14 May 2014 11:31:15 -0300, "Joao S. O. Bueno" < >> [email protected]> wrote: >>> +1 for an official policy that comes with a "permanent maintainer for >>> this platform required" as part of the list >>> of requisites. >>> >>> js >>> -><- >>> >>> On 14 May 2014 11:20, Brett Cannon wrote: Over the past week or so there have been 2 patches to add support for various UNIX OSs. Now I thought we had stopped trying to add new >> esoteric OSs (e.g. I had never heard of MirOS until the patch for it came in), >> but I can't find a PEP that spells out what it takes to get a platform >> supported (http://legacy.python.org/dev/peps/pep-0011/ is about removing >> platforms, not keeping them or adding them unless you are re-adding one which apparently just takes a volunteer). Do we want an official policy written down in a PEP (yes, I can write >> it)? Should I keep closing these patches and saying that we are not adding support for new operating systems and be hand-wavy about it? >> >> In addition to a maintainer (who I think doesn't have to be a committer, >> though that would be ideal), I think a maintained buildbot should be a >> requirement for formal support. >> > > I would think someone how is/would be a core dev and a *stable* buildbot > are requirements. so, are aarch64-linux-gnu and powerpc64le-linux-gnu supported? I assume there are no buildbots and there won't be any for a long time. Otoh various distros do ship python on these architectures. Or are these just new architectures for an existing platform? If yes, then we should ask about architecture support too. The most prominent linux example are some RTLD constants which differ across some architectures. Matthias ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where is our official policy of what platforms we do support?
On Wed May 14 2014 at 11:33:27 AM, Matthias Klose wrote: > Am 14.05.2014 17:08, schrieb Brett Cannon: > > On Wed May 14 2014 at 11:02:50 AM, R. David Murray < > [email protected]> > > wrote: > > > >> On Wed, 14 May 2014 11:31:15 -0300, "Joao S. O. Bueno" < > >> [email protected]> wrote: > >>> +1 for an official policy that comes with a "permanent maintainer for > >>> this platform required" as part of the list > >>> of requisites. > >>> > >>> js > >>> -><- > >>> > >>> On 14 May 2014 11:20, Brett Cannon wrote: > Over the past week or so there have been 2 patches to add support for > various UNIX OSs. Now I thought we had stopped trying to add new > >> esoteric > OSs (e.g. I had never heard of MirOS until the patch for it came in), > >> but I > can't find a PEP that spells out what it takes to get a platform > >> supported > (http://legacy.python.org/dev/peps/pep-0011/ is about removing > >> platforms, > not keeping them or adding them unless you are re-adding one which > apparently just takes a volunteer). > > Do we want an official policy written down in a PEP (yes, I can write > >> it)? > Should I keep closing these patches and saying that we are not adding > support for new operating systems and be hand-wavy about it? > >> > >> In addition to a maintainer (who I think doesn't have to be a committer, > >> though that would be ideal), I think a maintained buildbot should be a > >> requirement for formal support. > >> > > > > I would think someone how is/would be a core dev and a *stable* buildbot > > are requirements. > > so, are aarch64-linux-gnu and powerpc64le-linux-gnu supported? I assume > there > are no buildbots and there won't be any for a long time. Otoh various > distros do > ship python on these architectures. Or are these just new architectures > for an > existing platform? If yes, then we should ask about architecture support > too. > The most prominent linux example are some RTLD constants which differ > across > some architectures. > I consider CPU and compiler separate things. As long as we have a buildbot covering the CPU or compiler somehow I say they are covered (and someone is willing to help make sure they continue to work). I'm not going to say that we need a BSD ARM buildbot and a Linux ARM machine; having *a* machine with ARM should be enough to shake out most arch-specific issues IMO. Same goes with compilers. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where is our official policy of what platforms we do support?
I wonder if one or more people who maintain unofficial forks on minority platforms (OS/2, VMS, etc) could create an informational PEP about the process (benefits and pitfalls) of that kind of effort? Skip ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Questions regarding Windows buildbots
Brian Curtin writes: > On Mon, May 12, 2014 at 5:16 PM, Claudiu Popa wrote: (...) >> - If we can acquire the privilege by elevating our process, does the >> Windows buildbots have UAC >> enabled and if so, how's the notification setting configured? For >> instance, elevating a process will >> trigger a new UAC window with the message "Do you want to allow the >> following program from an unknown publisher to make changes to this >> computer?" on the recommended configuration, but this doesn't happen >> when the configuration is set to "Never notify". > > That probably depends on how each machine is setup. If they happen to > get blocked on any individual slave, we'll just have to ask the owner > to change that setting. For reference, my Windows 7 slave (bolen-windows7) is currently running with stock UAC settings, so I believe would prompt in such a scenario. The slave does run all builds with Windows error dialogs disabled, but I doubt that covers UAC. It's certainly no problem to disable the UAC prompting if it would help or if that becomes a more useful setting for the buildbot environment. It probably fits better with my existing model of disabling other sorts of error popups anyway, but just isn't something we've run up against yet in the build process. > Currently there are no Windows build slaves running as administrator. > I used to have one but the machine died and I never replaced it. I > also said a few months ago that I would get one setup again, but that > hasn't happened yet. I can get a new machine up and running but > probably not until next week as I'm at a conference. Yes - my slaves (XP and Win7) are running under administrative accounts, but not the literal Administrator account. Though I'm guessing this topic may be moot for the XP slave as it doesn't have UAC. Claudiu, if you've got any specific test code you'd like to have executed on either of my slaves to see how it behaves, I'd be happy to help. Just contact me directly. -- David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where is our official policy of what platforms we do support?
On 15 May 2014 01:52, Brett Cannon wrote: > > I consider CPU and compiler separate things. As long as we have a buildbot > covering the CPU or compiler somehow I say they are covered (and someone is > willing to help make sure they continue to work). I'm not going to say that > we need a BSD ARM buildbot and a Linux ARM machine; having a machine with > ARM should be enough to shake out most arch-specific issues IMO. Same goes > with compilers. We also handle some of that compatibility testing over in distro land. The feedback loop is a bit longer, but arch specific bugs are pretty rare anyway. For example: yes, CPython runs just fine on IBM s390x main frames, no, I'm not going to try to arrange for an s390x BuildBot upstream because that would be painful, and abstracting away CPU architecture issues is a key part of what the OS layer is for in the first place :) Anyway, +1 from me for expanding PEP 11 to also cover: - some rules of thumb for what kind of OS specific patches are acceptable to improve handling of unknown/unsupported OSes (e.g. switch from explicit OS detection to equivalent feature detection, yes, explicitly listing an unsupported OS in a conditional check, no) - some guidelines for what's needed for a new OS to be added as officially supported (with age and popularity likely being worth taking into account) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where is our official policy of what platforms we do support?
On 14May2014 14:45, Brett Cannon wrote: On Wed May 14 2014 at 10:43:18 AM, Antoine Pitrou wrote: On Wed, 14 May 2014 14:20:26 + Brett Cannon wrote: > Over the past week or so there have been 2 patches to add support for > various UNIX OSs. Now I thought we had stopped trying to add new esoteric > OSs (e.g. I had never heard of MirOS until the patch for it came in), but I > can't find a PEP that spells out what it takes to get a platform supported ( > http://legacy.python.org/dev/peps/pep-0011/ is about removing platforms, > not keeping them or adding them unless you are re-adding one which > apparently just takes a volunteer). OTOH you can fix a platform bug without officially supporting it. If someone files an OpenBSD-specific patch, it may make sense to commit it even without officially supporting OpenBSD. In practice it all depends on how intrusive / reasonable the patch is, and whether it is working around a platform-specific bug rather than a standards-compliant limitation. (we could call those "stochastically supported platforms" :-)) Very true, but these patches are all for e.g. configure to recognize a specific platform by listing them in some constant. Changing code to be more general I have no issue with since that's just good practice. Recognition of a special platform isn't "full support", just addition of recognition making possible partial support for special cases. Unless that makes for some horrendous recognition decision tree somewhere I would have thought that's a pretty low bar to accept, and worth doing. Leaving aside any bug actually fixed, it makes it much easier for someone else to fix a platform specific bug by making a test constant available for turning on whatever special mode/code is wanted. More context on the example patch that triggered this query? Just 2c, Cameron Simpson ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where is our official policy of what platforms we do support?
Main problem with rare platform support is not breaking it accidentally, since without buildbots we won't know when it's broken. This is why we don't make any promises. On May 14, 2014 9:02 PM, "Cameron Simpson" wrote: > On 14May2014 14:45, Brett Cannon wrote: > >> On Wed May 14 2014 at 10:43:18 AM, Antoine Pitrou >> wrote: >> >>> On Wed, 14 May 2014 14:20:26 + >>> Brett Cannon wrote: >>> > Over the past week or so there have been 2 patches to add support for >>> > various UNIX OSs. Now I thought we had stopped trying to add new >>> esoteric >>> > OSs (e.g. I had never heard of MirOS until the patch for it came in), >>> but I >>> > can't find a PEP that spells out what it takes to get a platform >>> supported ( >>> > http://legacy.python.org/dev/peps/pep-0011/ is about removing >>> platforms, >>> > not keeping them or adding them unless you are re-adding one which >>> > apparently just takes a volunteer). >>> >>> OTOH you can fix a platform bug without officially supporting it. If >>> someone files an OpenBSD-specific patch, it may make sense to commit it >>> even without officially supporting OpenBSD. In practice it all depends >>> on how intrusive / reasonable the patch is, and whether it is working >>> around a platform-specific bug rather than a standards-compliant >>> limitation. >>> >>> (we could call those "stochastically supported platforms" :-)) >>> >> >> Very true, but these patches are all for e.g. configure to recognize a >> specific platform by listing them in some constant. Changing code to be >> more general I have no issue with since that's just good practice. >> > > Recognition of a special platform isn't "full support", just addition of > recognition making possible partial support for special cases. Unless that > makes for some horrendous recognition decision tree somewhere I would have > thought that's a pretty low bar to accept, and worth doing. > > Leaving aside any bug actually fixed, it makes it much easier for someone > else to fix a platform specific bug by making a test constant available for > turning on whatever special mode/code is wanted. > > More context on the example patch that triggered this query? > > Just 2c, > Cameron Simpson > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
