[python-committers] Re: Proposed tiered platform support
I wonder if putting this into a PEP might be a little heavyweight in terms of making adjustments to the platform triples and their priorities? I perhaps think something that's a look aside table with a defined policy of how to move various triples up and down might work better? On Fri, 11 Mar 2022, 10:36 am Brett Cannon, wrote: > I brought this up on python-dev at > https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/ > , and the feedback seemed supportive. As such, I am bringing a draft of > what I'm thinking will go into PEP 11 with a bunch of `XXX` placeholders > for people to help me fill in to see how this will look overall. > > For any platform(s) you support, please reply with any relevant details > that should be added to the relevant tables below. Once I have these > details I will loop back with the proposed update to PEP 11 and make sure > everyone is still on board with the proposal. > > = > Tiers > = > > Tier 1 > == > > - `Test suite failures < > https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>`__ > block releases. > - Changes which would break the ``main`` branch are not allowed to be > merged; > any breakage may be reverted immediately. > - All core developers are responsible to keep these platforms working. > - Promotion of this tier requires consensus/SC approval. > > === = > Target Triple Notes > === = > i686-windows-msvc > x86_64-windows-msvc > x86_64-apple-darwin macOS 11 > x86_64-linux-gnuglibc 2.31 |ubuntu-20_01|_ > === = > > .. [ubuntu-20_01] > https://launchpad.net/ubuntu/+source/glibc/2.31-0ubuntu9.4 > > > Tier 2 > == > > - Must have a stable buildbot. > - At least **two** core developers are signed up to support the platform. > - Changes which break any of these platforms are to be reverted within 24 > hours. > - Failures of these platforms block a release. > - Promotion of this tier requires consensus/SC approval. > > == == > == > Target Triple Notes Buildbot > Contacts > == == > == > aarch64-apple-darwin XXX > https://buildbot.python.org/all/#/builders/725 XXX > aarch64-linux-gnu glibc XXX [fedora-stable]_ > https://buildbot.python.org/all/#/builders/125 XXX >glibc 2.28 [RHEL8]_ > https://buildbot.python.org/all/#/builders/529 XXX > aarch64-windows-msvc XXX > https://buildbot.python.org/all/#/builders/729 XXX > powerpc64-linux-gnuglibc XXX > https://buildbot.python.org/all/#/builders/237 XXX > powerpcle-linux-gnuglibc XXX > https://buildbot.python.org/all/#/builders/90 XXX > s309x-linux-gnuglibc XXX > https://buildbot.python.org/all/#/builders/223 XXX >glibc 2.28 [RHEL8]_ > https://buildbot.python.org/all/#/builders/509 XXX >glibc 2.17 [RHEL7]_ > https://buildbot.python.org/all/#/builders/179 XXX > x86_64-linux-gnu glibc 2.17 [RHEL7]_ > https://buildbot.python.org/all/#/builders/15 XXX > x86_64-unknown-freebsd XXX > https://buildbot.python.org/all/#/builders/172 XXX > == == > == > > .. [fedora-stable] XXX > .. [RHEL8] https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_8 > .. [RHEL7] > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.0_release_notes/sect-red_hat_enterprise_linux-7.0_release_notes-compiler_and_tools-glibc > > > Tier 3 > == > > - Must have a stable buildbot. > - Code may be checked into ``main`` for the platform. > - At least **one** core developer is signed up to support the platform. > - Test failures do **not** block releases. > - Promotion to this tier is self-service. > > = == > == > Target Triple Notes Buildbot > Contacts > = == > == > wasm32-unknown-emscripten XXXXXX > Brett Cannon, Christian Heimes > wasm32-unknown-wasi XXXXXX > Brett Cannon, Christian Heimes > = == > == > > > All other platforms > === > > - Only code which either supports a higher-tier platform or is a general > improvement may be checked in. > ___ > python-committers mailing list --
[python-committers] Re: PEP 563 and Python 3.10.
While I have not been involved in the release process for like 15 years or more, I would like to point out that breaking changes mean the distros are less likely to ship them, and be less likely to trust updates. Trying to get RH to stop shipping 1.5.2 was a huge effort. Always, any time when you might need to break compat it's a huge risk. On Wed, 21 Apr 2021, 4:58 am Thomas Wouters, wrote: > > (Starting a new thread so as not to derail any of the ongoing discussions.) > > Thanks, everyone, for your thoughts on Python 3.10 and the impact of PEP > 563 (postponed evaluation of annotations) becoming the default. The > Steering Council has considered the issue carefully, along with many of the > proposed alternatives and solutions, and we’ve decided that at this point, > we simply can’t risk the compatibility breakage of PEP 563. We need to roll > back the change that made stringified annotations the default, at least for > 3.10. (Pablo is already working on this.) > > To be clear, we are not reverting PEP 563 itself. The future import will > keep working like it did since Python 3.7. We’re delaying making PEP 563 > string-based annotations the default until Python 3.11. This will give us > time to find a solution that works for everyone (or to find a feasible > upgrade path for users who currently rely on evaluated annotations). Some > considerations that led us to this decision: > > - PEP 563’s default change is clearly too disruptive to downstream users > and third-party libraries to happen right now. We can’t risk breaking even > a small subset of the FastAPI/pydantic users, not to mention other uses of > evaluated type annotations that we’re not aware of yet. > - PEP 563 provides no warning to users of the feature it’s disabling. > Without that, we can’t expect users to be aware of the upcoming breakage. > The lack of a warning was by design, and made sense in a world where type > annotations were only consumed by static type checkers --- but that’s not > actually the situation we’re in. There are clearly existing real-world, > run-time uses of type annotations that would be adversely affected by this > change. > - Originally, PEP 563 was scheduled to take effect in Python 4, and this > changed recently (after the discussion in the Language Summit of 2020). > It's possible that third-party libraries and users didn’t plan to react in > the current time frame as they were not aware of this change in timing. > - There isn’t enough time to properly discuss PEP 649 or any of the > alternatives before the beta 1 deadline, and we really need to make sure we > don’t compound errors here. We need to look for a long term solution, > which isn’t possible while still maintaining the release deadlines of > Python 3.10. That means we’re also deferring PEP 649 to Python 3.11. > > In the Steering Council’s unanimous opinion, rolling back the default flip > for stringified annotations in Python 3.10 is the least disruptive of all > the options. > > We need to continue discussing the issue and potential solutions, since > this merely postpones the problem until 3.11. (For the record, postponing > the change further is not off the table, either, for example if the final > decision is to treat evaluated annotations as a deprecated feature, with > warnings on use.) > > For what it’s worth, the SC is also considering what we can do to reduce > the odds of something like this happening again, but that’s a separate > consideration, and a multi-faceted one at that. > > For the Steering Council, > Thomas. > -- > Thomas Wouters > > Hi! I'm an email virus! Think twice before sending your email to help me > spread! > ___ > python-committers mailing list -- python-committers@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committers@python.org/message/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/ULSWULZIBTYQ5GRBTLRQGNKQ525S7WJC/ Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Transfer of power
As someone who's not been involved for some time now, but was release manager for a three or four years (2.3.1 through to 2.5.1), trying to have the release manager also be a decider of potentially controversial things doesn't seem scalable. Getting a release out is a heck of a lot of work, both the actually cutting the alphas, betas, , and also triaging issues that comes up and chasing people up for fixes. I'm not sure what the proper governance structures should be, but they absolutely shouldn't be dumping extra load onto the release manager. On Fri, Jul 13, 2018, 3:49 AM Doug Hellmann wrote: > Excerpts from Yury Selivanov's message of 2018-07-12 13:29:21 -0400: > > On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou > wrote: > > > > > > > > > I'd like to point out that the N-virate idea doesn't handle a key > issue: > > > once you have a N-virate, how do you evolve its composition according > to > > > the implication and motivation of its members - but also to remarks or > > > frustation by non-virate contributors (especially new contributors who > > > will feel there's a perpetual category they're locked out of)? Do you > > > just wait for people to gently step down when required? > > > > One way would be to re-elect them every 5 or so years. Essentially, > > an N-virate is a dictator-like entity for a few years. > > > > Yury > > We've had good luck in the OpenStack community tying leadership to > release cycles. It causes elections more often (our cycles are 6 > months long), but people tend to step up for several cycles in a > row so that hasn't been a cause of excessive turnover. Having > frequent opportunities for folks to step down gracefully when they > need or want to also means no one feels like they are signing up > for an indefinite time commitment. > > For a multi-person group, staggered elections where only a portion > of the group is up for election at one time, also provides some > consistency when there is turnover. > > Doug > ___ > python-committers mailing list > python-committers@python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Trunk is ready for 3.4.0a2 work
http://www.voodoochilli.net/artwork/illustration/chickens-of-war/ On Aug 4, 2013 4:34 PM, Larry Hastings la...@hastings.org wrote: All the release engineering work for 3.4.0a1 has been merged. Cry havoc, and let slip the checkins of war! */arry* ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Policy for committing to 2.7
Maybe time it so when we *would* have released a 2.8 (18 months or so after 2.7) is when it goes into critical/security fixes only? On Jun 22, 2013 11:50 PM, Eli Bendersky eli...@gmail.com wrote: On Sat, Jun 22, 2013 at 12:35 PM, Barry Warsaw ba...@python.org wrote: On Jun 22, 2013, at 12:02 PM, Eli Bendersky wrote: I may be missing something, but do we have a policy of what we're supposed to commit to the 2.7 branch at this point? I was under the impression that it's only bug fixes, documentation, and maybe tests. But it seems that there are developers who see it otherwise. Strongly agree. One additional allowed category of changes are build system fixes, e.g. so that 2.7 can still be built on newer versions of operating systems it already supports. Yes, this makes sense too. In general there seems to be an agreement, so it would be great to document in some place. Many years will pass before we have another special release like Python 2.7, so it's worth spending an extra few minutes to have this written down. PEP 404 seems to be a reasonable place - any objections? Benjamin, what do you think? Eli ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Googler Python committers
Yep. People tend to stop being so active when they join Google (including me) :-( There's a fair number of current or ex Python dev folks at Google. Guido, Jeremy H, Alex M, Neal N, Thomas W off the top of my head, I am certain there's a bunch more... On Oct 17, 2012 4:12 AM, Gregory P. Smith g...@krypto.org wrote: On Tue, Oct 16, 2012 at 7:44 AM, Chris Jerdonek chris.jerdo...@gmail.comwrote: On Tue, Oct 16, 2012 at 6:32 AM, Eli Bendersky eli...@gmail.com wrote: I had the privilege of joining Google's Mountain View office yesterday, and was wondering who else from the core development team works there, or in Google in general (in addition to Guido, of course). Congrats, Eli! This may not be complete or accurate, but (and this tip can be useful to everybody), the list of committers here has a column that in some cases shows a company. Several people from Google are listed: http://bugs.python.org/user?iscommitter=1@action=search@sort=username@pagesize=300 That isn't up to date and users cannot edit their own information (at least it tells _me_ I'm not authorized when I submit the edit form on my own info) so I wouldn't trust that page. Yet another silly profile to maintain in yet another location. sigh. There are many Google committers though not all are active. -gps ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Googler Python committers
Fair enough - I did say tend. :) On Wed, Oct 17, 2012 at 11:33 AM, Gregory P. Smith g...@krypto.org wrote: On Tue, Oct 16, 2012 at 5:06 PM, Anthony Baxter anthonybax...@gmail.com wrote: Yep. People tend to stop being so active when they join Google (including me) :-( My activity increased. I would not make that statement. -gps ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] On track for Python 2.6.4 final this Sunday?
I strongly urge another release candidate. But then, I am not doing the work, so take that advice for what it is... On Oct 14, 2009 10:18 AM, Barry Warsaw ba...@python.org wrote: On Oct 13, 2009, at 6:10 PM, Martin v. Löwis wrote: I always thought that the idea of a release ... No, but let's do one anyway! So, we can either make Sunday's release rc2 and do the final release one week later, or I can try to get an rc2 out in the next day or two, with a final release mid-next week. Thoughts? -Barry ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Misc/NEWS entries added to released versions
Often the NEWS entry ends up being rewritten from the commit message to be more user-focussed description of the change... On Sep 14, 2009 6:33 PM, Georg Brandl g.bra...@gmx.net wrote: Brett Cannon schrieb: brainstorm: It'd be nicer if we could generate the file from another source, perhaps ke... We should just switch to Mercurial :) I've already hacked up a hg extension to automatically fill the commit message with the changes in a NEWS or CHANGELOG file. This works quite well -- you add the short but nice description to NEWS, do hg commit, and the editor pops up where you can either accept the message consisting of only the changes in NEWS, or add some more stuff that's not interesting to users. cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ python-committers mailing list python-committ...@py... ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Cutting Python 2.6
Sure, but that's more fiddly. From experience, when you're cutting releases, making things as simple as possible is a good thing. On Thu, Oct 2, 2008 at 11:35 AM, Guido van Rossum [EMAIL PROTECTED] wrote: There should be a way to re-tag only the file(s) that contain the fix. On Wed, Oct 1, 2008 at 4:00 PM, Anthony Baxter [EMAIL PROTECTED] wrote: If there's a screwup, and you need to recut the branch, you want to be sure someone else hasn't been helpful and added something else to the repo. On Thu, Oct 2, 2008 at 9:37 AM, Jesus Cea [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barry Warsaw wrote: IIUC, the critical bottleneck is tagging the tree, so the RM needs to make it far enough through the PEP to get to that point. Of course that does mean freezing the tree, and I don't think it's too difficult to do that. I always found strange the need to freeze the tree. When a svn tag is created, the build process should use that tag to extract the files and build the release, while the repository is being updated normally. In fact in a *.0 release, the tag should be a branch actually. Sure I'm missing something... - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSOP7oJlgi5GaxT1NAQKmwQP/XTepaw9fFqf4b3VWsocvj0s4sb7THKgF cVi7Rf424YD+i7AJzMe0aFMEsrhvor1Ma/KMMXdypymxXkUapuJmLIP6R3BWZzyp sCDzRifhgHJg6LCq3TpIPvYseurUR1P0hgLZEKf5K/EAO+BJc6RIknBOgNS0RuHG SNs5cVMhe7g= =VRp9 -END PGP SIGNATURE- ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Cutting Python 2.6
That's why I wrote the welease.py script. Dunno if you've been using it. I wanted to make the release process as foolproof as possible so I wouldn't screw it up :-) On Thu, Oct 2, 2008 at 12:02 PM, Barry Warsaw [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 1, 2008, at 9:47 PM, Anthony Baxter wrote: Sure, but that's more fiddly. From experience, when you're cutting releases, making things as simple as possible is a good thing. Especially when a lot of the process is scripted. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSOQry3EjvBPtnXfVAQJI7wP9HOtS7jMhOX4g47PZ4mNUs6VYywBEV7uo LZo0EuqJHiWfOHjkmpAipxo2ApXhhqpvFgGNtDBx4lPnsjbJbsrg2TO2/F8fwkMA O9oR3oQ5opUD5tONwE5q/1GHJPssw+UazqPP3262+K0UFS5IqwDlDu2msx3/H+sv YaB6kAykvMA= =Z8ir -END PGP SIGNATURE- ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
