+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 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 May 14 2014 at 10:43:18 AM, Antoine Pitrou wrote:

On Wed, 14 May 2014 14:20:26 +0000 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.

On Wed May 14 2014 at 11:02:50 AM, R. David Murray 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

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.

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 < 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 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 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

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:

...

...

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 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 _______________________________________________ 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 Thu, 15 May 2014 08:20:03 -0500 Skip Montanaro wrote:

On Wed, May 14, 2014 at 11:05 PM, Guido van Rossum 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 10:24:45 AM, Skip Montanaro wrote:

On Thu, May 15, 2014 at 8:26 AM, Antoine Pitrou 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, 15 May 2014 09:40:33 -0500 Skip Montanaro wrote:

On Thu, May 15, 2014 at 9:35 AM, Brett Cannon 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.

Am 15.05.14 16:20, schrieb Skip Montanaro:

On Thu, May 15, 2014 at 8:26 AM, Antoine Pitrou 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