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?
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
Am 14.05.14 16:28, schrieb Barry Warsaw:
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.
I'd be careful to use the word "support". AFAIK, we do not offer support for Python on any platform, beyond accepting bug reports in the bug tracker. Paid support for Python is certainly offered by some companies, but not by us. IIUC, Brett is asking the question "What platforms is CPython supposed to work on?". Thanks to autoconf, it is impossible to give a complete list of such platforms. It might be that Python builds just fine, with no changes required, on a system that we've never heard of. So if you want to give a complete list of "supported" platforms, it might be the question "What platforms do we care about?", in the sense that someone would be willing to invest time if it stops working. Again, as we do not offer paid support, this list might get misleadingly long. I'd be personally willing to invest time looking into a lot of problems - just not within the next 12 months (but surely some day :-) The only reasonable positive platform list I can think of is "What platforms do we consider release-critical?", in the sense of not letting a release proceed if it fails to work on one of these platforms. We've had such a list for a long time, it is: - Microsoft Windows - Linux - Apple Mac OS X Regards, Martin
+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 <bcannon@gmail.com> 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 Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
On Wed, 14 May 2014 11:31:15 -0300, "Joao S. O. Bueno" <jsbueno@python.org.br> 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 <bcannon@gmail.com> 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
On Wed May 14 2014 at 11:02:50 AM, R. David Murray <rdmurray@bitdance.com> 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 <bcannon@gmail.com> 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
On Wed, 14 May 2014 11:31:15 -0300, "Joao S. O. Bueno" < jsbueno@python.org.br> wrote: 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.
Am 14.05.2014 17:08, schrieb Brett Cannon:
On Wed May 14 2014 at 11:02:50 AM, R. David Murray <rdmurray@bitdance.com> 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 <bcannon@gmail.com> 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
On Wed, 14 May 2014 11:31:15 -0300, "Joao S. O. Bueno" < jsbueno@python.org.br> wrote: 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
On Wed May 14 2014 at 11:33:27 AM, Matthias Klose <doko@ubuntu.com> wrote:
Am 14.05.2014 17:08, schrieb Brett Cannon:
On Wed May 14 2014 at 11:02:50 AM, R. David Murray < rdmurray@bitdance.com> 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 <bcannon@gmail.com> 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
On Wed, 14 May 2014 11:31:15 -0300, "Joao S. O. Bueno" < jsbueno@python.org.br> wrote: 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.
On 15 May 2014 01:52, Brett Cannon <bcannon@gmail.com> 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 | ncoghlan@gmail.com | Brisbane, Australia
On Wed, 14 May 2014 14:20:26 +0000 Brett Cannon <bcannon@gmail.com> 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.
On Wed May 14 2014 at 10:43:18 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Wed, 14 May 2014 14:20:26 +0000 Brett Cannon <bcannon@gmail.com> 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.
On 14May2014 14:45, Brett Cannon <bcannon@gmail.com> wrote:
On Wed May 14 2014 at 10:43:18 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Wed, 14 May 2014 14:20:26 +0000 Brett Cannon <bcannon@gmail.com> 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 <cs@zip.com.au>
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" <cs@zip.com.au> wrote:
On 14May2014 14:45, Brett Cannon <bcannon@gmail.com> wrote:
On Wed May 14 2014 at 10:43:18 AM, Antoine Pitrou <solipsis@pitrou.net> 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
On Wed, 14 May 2014 14:20:26 +0000 Brett Cannon <bcannon@gmail.com> wrote: 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 <cs@zip.com.au> _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ guido%40python.org
On Wed, May 14, 2014 at 11:05 PM, Guido van Rossum <guido@python.org> wrote:
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.
Should we (or do we) offer to run (unofficial) buildbots for maintainers of minority platforms where possible? For example, I have no idea if a buildbot for MirOS is even feasible, but if the guy who submitted the patch is amenable and it is possible to run a buildbot slave for that OS, it still might be useful to have a "one stop" place for this. If failing, such buildbots wouldn't block a release, but would still provide tools for people to track down the source of breakage. Skip
On Thu, 15 May 2014 08:20:03 -0500 Skip Montanaro <skip@pobox.com> wrote:
On Wed, May 14, 2014 at 11:05 PM, Guido van Rossum <guido@python.org> wrote:
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.
Should we (or do we) offer to run (unofficial) buildbots for maintainers of minority platforms where possible? For example, I have no idea if a buildbot for MirOS is even feasible, but if the guy who submitted the patch is amenable and it is possible to run a buildbot slave for that OS, it still might be useful to have a "one stop" place for this. If failing, such buildbots wouldn't block a release, but would still provide tools for people to track down the source of breakage.
We already have such buildbots, they are in the "unstable" category. You can browse through existing buildbots here: https://www.python.org/dev/buildbot/ In the case of MirOS, though, I'm unsure core developers would proactively fix failures on such a niche platform :-) Regards Antoine.
On Thu, May 15, 2014 at 8:26 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
We already have such buildbots, they are in the "unstable" category. You can browse through existing buildbots here: https://www.python.org/dev/buildbot/
I can't see how to distinguish "stable" from "unstable" (or to view just the "unstable" category. What do those two categories have to do with "supported" and "unsupported"? Skip
On Thu May 15 2014 at 10:24:45 AM, Skip Montanaro <skip@pobox.com> wrote:
On Thu, May 15, 2014 at 8:26 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
We already have such buildbots, they are in the "unstable" category. You can browse through existing buildbots here: https://www.python.org/dev/buildbot/
I can't see how to distinguish "stable" from "unstable" (or to view just the "unstable" category.
Take http://buildbot.python.org/all/waterfall?category=3.x.stable&category=3.x.unstableand remove the category GET argument that you don't want to see, e.g. to only see unstable buildbots use http://buildbot.python.org/all/waterfall?category=3.x.unstable
What do those two categories have to do with "supported" and "unsupported"?
Antoine can give the definitive answer, but I view stable buildbots as staying up and testing critical platforms. I.e. when I submit a patch I make sure the stable buildbots are always green (unless it's a transient failure) and I don't worry about the unstable ones (I view them as more informative than necessary). Basically red stable buildbot should block a release. -Brett
On Thu, May 15, 2014 at 9:35 AM, Brett Cannon <bcannon@gmail.com> wrote:
I view stable buildbots as staying up and testing critical platforms.
Would "supported" and "unsupported" (or "critical" and "optional"?) make more sense? "Unstable" suggests "broken" to me, not "we don't really care about these." S
On Thu, 15 May 2014 09:40:33 -0500 Skip Montanaro <skip@pobox.com> wrote:
On Thu, May 15, 2014 at 9:35 AM, Brett Cannon <bcannon@gmail.com> wrote:
I view stable buildbots as staying up and testing critical platforms.
Would "supported" and "unsupported" (or "critical" and "optional"?) make more sense? "Unstable" suggests "broken" to me, not "we don't really care about these."
I don't know who came up with these names in the first place. However there's a slight nuance here: some platform may be supported, but still some buildbot end up in the "unstable" category if it has issues of its own (for example the machine has a flaky network connection, etc.). And indeed there are Linux and Windows machines in the "unstable" category. Regards Antoine.
On Thu, 15 May 2014 19:14:55 +0200, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Thu, 15 May 2014 09:40:33 -0500 Skip Montanaro <skip@pobox.com> wrote:
On Thu, May 15, 2014 at 9:35 AM, Brett Cannon <bcannon@gmail.com> wrote:
I view stable buildbots as staying up and testing critical platforms.
Would "supported" and "unsupported" (or "critical" and "optional"?) make more sense? "Unstable" suggests "broken" to me, not "we don't really care about these."
I don't know who came up with these names in the first place. However there's a slight nuance here: some platform may be supported, but still some buildbot end up in the "unstable" category if it has issues of its own (for example the machine has a flaky network connection, etc.). And indeed there are Linux and Windows machines in the "unstable" category.
There's also nothing stopping us from putting a "niche platform" buildbot into the stable group if it normally builds fine. I suppose it would be pretty much supported by default then, though, if it being red was a release blocker. But we could decide to ignore a red 'niche' buildbot at release time; so, I think 'stable' vs 'unstable' is indeed the most descriptive: unstable buildbots are the ones that turn red "randomly"[*], or are always red because no one has fixed whatever the problem is (which might be on the buildbot or in our code). --David [*] Yes, our stable platforms do that sometimes too, but those are test instabilities, whereas unstable buildbots fail tests other than the known unstable tests.
Am 15.05.14 16:20, schrieb Skip Montanaro:
On Thu, May 15, 2014 at 8:26 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
We already have such buildbots, they are in the "unstable" category. You can browse through existing buildbots here: https://www.python.org/dev/buildbot/
I can't see how to distinguish "stable" from "unstable" (or to view just the "unstable" category. What do those two categories have to do with "supported" and "unsupported"?
There are two competing definitions of "stable" vs. "unstable" when it comes to buildbots. 1. "stable buildbot" (my preferred definition) * the buildbot is available most of the time, an operator will deal with it when it happens to go down, and the builds always complete. * consequentially, an unstable buildbot is one that tends to disconnect, and takes a long time for the operator to recover 2. "stable platform" * all tests are expected to pass all the time; i.e. there are no tests that randomly fail, and no platform-specific failures * thus, a failed test is an indication that a new bug has been introduced When Antoine talked about "unofficial" buildbots, he was referring to the fact that we accept nearly any buildbot offered, but put them into the unstable category, which they often belong to by either definition of unstable. Regards, Martin
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
participants (11)
-
"Martin v. Löwis" -
Antoine Pitrou -
Barry Warsaw -
Brett Cannon -
Cameron Simpson -
Guido van Rossum -
Joao S. O. Bueno -
Matthias Klose -
Nick Coghlan -
R. David Murray -
Skip Montanaro