<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Feb 20, 2015 at 1:47 PM Brett Cannon <<a href="mailto:bcannon@gmail.com">bcannon@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I just realized I actually never committed this change. Assuming no new objections I'll commit this in the near future (promise this time =).</div></blockquote><div><br></div><div>My proposed changes have now been committed. Thanks to everyone who provided feedback!</div><div><br></div><div>This should hopefully make it much clearer what it takes to accept platform-specific patches (i.e., core dev willing to maintain the compatibility and a stable buildbot for the platform).</div><div><br></div><div>For those trying to get Python working on Android, this will mean a conversation will be necessary about how to get a buildbot or some form or regular testing set up in order to accept Android-specific patches (along with a core dev willing to keep an eye on the compatibility).</div><div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote">On Fri May 16 2014 at 1:51:00 PM Brett Cannon <<a href="mailto:bcannon@gmail.com" target="_blank">bcannon@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here is some proposed wording. Since it is more of a clarification of what it takes to garner support -- which is just a new section -- rather than a complete rewrite I'm including just the diff to make it easier to read the changes.<div><br></div><div><br></div><div>
<p><b>diff -r 49d18bb47ebc pep-0011.txt</b></p>
<p><b>--- a/pep-0011.txt<span> </span>Wed May 14 11:18:22 2014 -0400</b></p>
<p><b>+++ b/pep-0011.txt<span> </span>Fri May 16 13:48:30 2014 -0400</b></p>
<p>@@ -2,22 +2,21 @@</p>
<p> Title: Removing support for little used platforms</p>
<p> Version: $Revision$</p>
<p> Last-Modified: $Date$</p>
<p>-Author: <a href="mailto:martin@v.loewis.de" target="_blank">martin@v.loewis.de</a> (Martin von Löwis)</p>
<p>+Author: Martin von Löwis <<a href="mailto:martin@v.loewis.de" target="_blank">martin@v.loewis.de</a>>,</p>
<p>+ Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>></p>
<p> Status: Active</p>
<p> Type: Process</p>
<p> Content-Type: text/x-rst</p>
<p> Created: 07-Jul-2002</p>
<p> Post-History: 18-Aug-2007</p>
<p>+ 16-May-2014</p>
<p> </p>
<p> </p>
<p> Abstract</p>
<p> --------</p>
<p> </p>
<p>-This PEP documents operating systems (platforms) which are not</p>
<p>-supported in Python anymore. For some of these systems,</p>
<p>-supporting code might be still part of Python, but will be removed</p>
<p>-in a future release - unless somebody steps forward as a volunteer</p>
<p>-to maintain this code.</p>
<p>+This PEP documents how an operating system (platform) garners</p>
<p>+support in Python as well as documenting past support.</p>
<p> </p>
<p> </p>
<p> Rationale</p>
<p>@@ -37,16 +36,53 @@</p>
<p> change to the Python source code will work on all supported</p>
<p> platforms.</p>
<p> </p>
<p>-To reduce this risk, this PEP proposes a procedure to remove code</p>
<p>-for platforms with no Python users.</p>
<p>+To reduce this risk, this PEP specifies what is required for a</p>
<p>+platform to be considered supported by Python as well as providing a</p>
<p>+procedure to remove code for platforms with little or no Python</p>
<p>+users.</p>
<p> </p>
<p>+Supporting platforms</p>
<p>+--------------------</p>
<p>+</p>
<p>+Gaining official platform support requires two things. First, a core</p>
<p>+developer needs to volunteer to maintain platform-specific code. This</p>
<p>+core developer can either already be a member of the Python</p>
<p>+development team or be given contributor rights on the basis of</p>
<p>+maintaining platform support (it is at the discretion of the Python</p>
<p>+development team to decide if a person is ready to have such rights</p>
<p>+even if it is just for supporting a specific platform).</p>
<p>+</p>
<p>+Second, a stable buildbot must be provided [2]_. This guarantees that</p>
<p>+platform support will not be accidentally broken by a Python core</p>
<p>+developer who does not have personal access to the platform. For a</p>
<p>+buildbot to be considered stable it requires that the machine be</p>
<p>+reliably up and functioning (but it is up to the Python core</p>
<p>+developers to decide whether to promote a buildbot to being</p>
<p>+considered stable).</p>
<p>+</p>
<p>+This policy does not disqualify supporting other platforms</p>
<p>+indirectly. Patches which are not platform-specific but still done to</p>
<p>+add platform support will be considered for inclusion. For example,</p>
<p>+if platform-independent changes were necessary in the configure</p>
<p>+script which was motivated to support a specific platform that would</p>
<p>+be accepted. Patches which add platform-specific code such as the</p>
<p>+name of a specific platform to the configure script will generally</p>
<p>+not be accepted without the platform having official support.</p>
<p>+</p>
<p>+CPU architecture and compiler support are viewed in a similar manner</p>
<p>+as platforms. For example, to consider the ARM architecture supported</p>
<p>+a buildbot running on ARM would be required along with support from</p>
<p>+the Python development team. In general it is not required to have</p>
<p>+a CPU architecture run under every possible platform in order to be</p>
<p>+considered supported.</p>
<p> </p>
<p> Unsupporting platforms</p>
<p> ----------------------</p>
<p> </p>
<p>-If a certain platform that currently has special code in it is</p>
<p>-deemed to be without Python users, a note must be posted in this</p>
<p>-PEP that this platform is no longer actively supported. This</p>
<p>+If a certain platform that currently has special code in Python is</p>
<p>+deemed to be without Python users or lacks proper support from the</p>
<p>+Python development team and/or a buildbot, a note must be posted in</p>
<p>+this PEP that this platform is no longer actively supported. This</p>
<p> note must include:</p>
<p> </p>
<p> - the name of the system</p>
<p>@@ -69,8 +105,8 @@</p>
<p> forward and offer maintenance.</p>
<p> </p>
<p> </p>
<p>-Resupporting platforms</p>
<p>-----------------------</p>
<p>+Re-supporting platforms</p>
<p>+-----------------------</p>
<p> </p>
<p> If a user of a platform wants to see this platform supported</p>
<p> again, he may volunteer to maintain the platform support. Such an</p>
<p>@@ -101,7 +137,7 @@</p>
<p> release is made. Developers of extension modules will generally need</p>
<p> to use the same Visual Studio release; they are concerned both with</p>
<p> the availability of the versions they need to use, and with keeping</p>
<p>-the zoo of versions small. The Python source tree will keep<span><b> </b></span></p>
<p>+the zoo of versions small. The Python source tree will keep</p>
<p> unmaintained build files for older Visual Studio releases, for which</p>
<p> patches will be accepted. Such build files will be removed from the</p>
<p> source tree 3 years after the extended support for the compiler has</p>
<p>@@ -223,6 +259,7 @@</p>
<p> ----------</p>
<p> </p>
<p> .. [1] <a href="http://support.microsoft.com/lifecycle/" target="_blank">http://support.microsoft.com/<u></u>lifecycle/</a></p>
<p>+.. [2] <a href="http://buildbot.python.org/3.x.stable/" target="_blank">http://buildbot.python.org/3.<u></u>x.stable/</a></p>
<p> </p>
<p> Copyright</p>
<p> ---------</p></div></blockquote></div></div></blockquote></div></div>