Change PEP 13 to make the Council Election use regular (multiwinner) approval voting, the same thing used for the PSF board elections, instead of restricting the number of votes to the number of seats in the Council.
Also updates the NEP 29 section to cover the latest wording
of that proposal, and makes it clear that mere acceptance
of the PEP doesn't prevent us from ever changing the release
process again.
Review PEP providing shared background for PEPs 602 and 605, covering both
common problem statements, and key differences in the proposals to address
those problems.
Co-Authored-By: Steve Dower <steve.dower@microsoft.com>
Co-Authored-By: Łukasz Langa <lukasz@langa.pl>
* Reword PEP 503 to match pip's URL lookup behavior
Clarify that the "filename" displayed in the anchor tag refers to the
final path component of the URL (instead of, say, the filename parameter
in the HTTP Content-Disposition header).
This matches pip's behavior: The URL's final path component is used to
determine the artifact's name (for selection), and its filename after
download.
* Replace "an URL" with "a URL"
* PEP 605: Add example user-facing docs
* example What's New subsection
* example alpha, beta, and rc announcements
* fix Python-Requires recommendation
* add rationale for allowing mid-stream alpha releases
* Stable ABI builds prior to 3.8 are also allowed
* Alphas are also for application testing
* Also put an ABI break marker in commit summaries
* Change ABI management to encourage pre-built wheels
* Actually dedicate a subsection to the 2 year cadence
* Update naming discussion for proposal changes
* Add discussion section for the pre-freeze flag
* Make the abstract much shorter (as suggested by Antoine Pitrou)
* Move example time line up and add pictures (based on PEP 602 images)
* Clarify 4 month window for X.Y.0a1 preparation
Co-Authored-By: Steve Dower <steve.dower@microsoft.com>
* proposes the regular publication of production-ready beta releases rather than making full X.Y.0 feature releases more common
* PEP 598 is being withdrawn in favour of this proposal
* originally drafted in collaboration with @zooba, @aeros167, and @h-vetinari
Matching the symbols permitted for x86_64 by GCC_4.3.0 require a limit of GCC_4.5.0 on i686 CentOS 6.
This does create the risk that 32-bit extension modules using `__extendxftf2` may not actually be portable to all 2010 era systems, but most of those other than RHEL/CentOS 6 have already hit the end of their respective support periods.
Samuel L. Setegne
Chris Angelico
Łukasz Langa
Jelle Zijlstra
Mike Pagel
Larry Hastings
Géry Ogam
Thomas Kluyver
wim glenn
Victor Stinner
T. Wouters
Brett Cannon
赵丰 (Zhao Feng)
Brandt Bucher
Nick Coghlan
Benjamin Peterson
Shayaan Syed Ali
Victor Stinner
Ned Deily
Tzu-ping Chung
Nathaniel J. Smith
Jason R. Coombs
Matthieu Darbois
Guido van Rossum
Esun Kim