I have a security question that I’d like to drop in the Python committers community, but I noticed that the archives for this list are open.
And I don’t want to post my question somewhere where it might give an idea to people…
I looked at the Inquisition group on discuss.python.org, but the last thread there is from 18 months ago (and was about the fact that it may be viewable to people outside the core devs:-).
Any suggestions where I can take my question?
--
Jack Jansen, <Jack.Jansen(a)cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman
Python 3.8.7 is the seventh maintenance release of Python 3.8. Go get it here:
https://www.python.org/downloads/release/python-387/ <https://www.python.org/downloads/release/python-387/>
Note: this is a bugfix release for the 3.8 series which was superseded by Python 3.9, currently the latest feature release series of Python 3. You can find the latest release of 3.9.x here <https://www.python.org/downloads/>.
Maintenance releases for the 3.8 series will continue at regular bi-monthly intervals, with 3.8.8 planned for February 2021.
macOS 11 Big Sur not fully supported
Python 3.8.7 is not yet fully supported on macOS 11 Big Sur. It will install on macOS 11 Big Sur and will run on Apple Silicon Macs using Rosetta 2 translation. However, a few features do not work correctly, most noticeably those involving searching for system libraries (vs user libraries) such as ctypes.util.find_library() and in Distutils. This limitation affects both Apple Silicon and Intel processors. We are looking into improving the situation for Python 3.8.8.
Python 3.9.1 <https://www.python.org/downloads/release/python-391/> provides full support for Big Sur and Apple Silicon Macs, including building natively on Apple Silicon Macs and support for universal2 binaries.
What’s new?
The Python 3.8 series contains many new features and optimizations over 3.7. See the “What’s New in Python 3.8 <https://docs.python.org/3.8/whatsnew/3.8.html>” document for more information about features included in the 3.8 series.
Detailed information about all changes made in version 3.8.7 specifically can be found in its change log <https://docs.python.org/release/3.8.7/whatsnew/changelog.html#python-3-8-7>. Note that compared to 3.8.6 this release also contains all changes present in 3.8.7rc1.
We hope you enjoy Python 3.8!
Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation.
Your friendly release team,
Ned Deily @nad <https://discuss.python.org/u/nad>
Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower>
Łukasz Langa @ambv <https://discuss.python.org/u/ambv>
I'm trying to merge this: https://github.com/python/cpython/pull/23855
It says that it's waiting on bedevere/issue-number and bedevere/news,
with status "Waiting for status to be reported". The PR is tagged with
"skip issue" and "skip news" (even though it has an issue). So I guess
these are inspected by bedevere, which isn't responding.
I've tried opening and closing the issue to re-trigger things, to no avail.
What can I do to commit this PR? Does bedevere need to be kicked into
life somehow? Is anyone else seeing this problem?
Thanks.
Eric
I got to know from Pablo that the release process is documented in a PEP
here: https://www.python.org/dev/peps/pep-0101/
I wonder if it makes sense for us to formalize this process by documenting
it on devguide, and adding any extra/missing information?
Happy to help.
--
Best,
Joannah Nanjekye
*"You think you know when you learn, are more sure when you can write, even
more when you can teach, but certain when you can program." Alan J. Perlis*
Voting closed at 2020-12-16 12:00 UTC as specified in PEP 8102.
Of 91 eligible voters, 74 cast ballots.
The top five vote-getters are:
Barry Warsaw
Brett Cannon
Carol Willing
Pablo Galindo Salgado
Thomas Wouters
No conflict of interest as defined in PEP 13 were observed.
Full results have been published to PEP 8102.
Eligible voters have received result notification emails from helios, and may return to
the system to audit/verify the results.
Thanks to all participants! It was an honor serving as the administrator for the
governance votes.
-Ee W. Durbin III
Director of Infrastructure
Python Software Foundation
As a result of this merge, I have so far received 3 emails with this
scary message. "This PR is stale because it has been open for 30 days
with no activity. Remove stale label or comment or this will be closed
in 5 days".
https://github.com/python/cpython/pull/23100#issuecomment-745680212https://github.com/python/cpython/pull/23098#issuecomment-745680248https://github.com/python/cpython/pull/22954#issuecomment-745680870
Issues with the change:
1. What use is the message and label? In
https://github.com/python/core-workflow/issues/93
Brett said that 'stale' meant that the PR was waiting on the contributor
-- no CLA or no requested revision. The purpose would then be to prompt
contributors and let committers know that they could not proceed (unless
the block was revision and one was willing to do it oneself).
The actual change appears to be strictly time based as none of the PRs
above are waiting on the author. So what *is* the purpose of actual change?
2. What is the appropriate waiting time? As I remember, most people in
the discussion I participated in suggested longer than a month, such as
6 months or a year. We seem to have been ignored. In any case, the
proper answer depends on the purpose.
One good result was triggering miss-islington to merge a stalled
backport PR with an approval and passed CI tests.
https://github.com/python/cpython/pull/22843#issuecomment-745681140
For checking miss-islinton backport PRs, I think flagging anythhing over
7 days would be about right.
3. Should 'stale' PRs be auto-closed? Since closing without merging
amounts to rejection, I am strongly opposed. Someone recently merged a
PR based on 2012 patches on bpo. Faster response to contributors would
be great, but using mindless automated rules will not get us there. In
any case, auto-closing after 35 days strikes me as madness.
As it turns out, Mariatta changed the original 5 days in the PR to -1,
meaning never, but forgot to change the message.
-------- Forwarded Message --------
Subject: [Python-checkins] Adding "stale" GitHub Action (GH-21247)
Date: Tue, 15 Dec 2020 14:59:00 -0500 (EST)
From: Mariatta <webhook-mailer(a)python.org>
Reply-To: python-dev(a)python.org
To: python-checkins(a)python.org
https://github.com/python/cpython/commit/9cc8fa6ac89e9ea3ee483675b3c373650f…
commit: 9cc8fa6ac89e9ea3ee483675b3c373650fc1bb3a
branch: master
author: Mariatta <Mariatta(a)users.noreply.github.com>
committer: Mariatta <Mariatta(a)users.noreply.github.com>
date: 2020-12-15T11:58:43-08:00
summary:
Adding "stale" GitHub Action (GH-21247)
Added the "stale" GitHub action to the CPython repo.
PR's older than 30 days will be labeled as stale using the "stale-pr" label.
Closes https://github.com/python/core-workflow/issues/372
Co-authored-by: Brett Cannon <brett(a)python.org>
files:
A .github/workflows/stale.yml
diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
new file mode 100644
index 0000000000000..706d8e11a2073
--- /dev/null
+++ b/.github/workflows/stale.yml
@@ -0,0 +1,19 @@
+name: Mark stale pull requests
+
+on:
+ schedule:
+ - cron: "0 0 * * *"
+
+jobs:
+ stale:
+
+ runs-on: ubuntu-latest
+
+ steps:
+ - uses: actions/stale@v3
+ with:
+ repo-token: ${{ secrets.GITHUB_TOKEN }}
+ stale-pr-message: 'This PR is stale because it has been open
for 30 days with no activity. Remove stale label or comment or this will
be closed in 5 days'
+ stale-pr-label: 'stale'
+ days-before-stale: 30
+ days-before-close: -1
Please ensure you have cast your ballots before 12:00 (noon) UTC December 16th, just under 15 hours from now.
All eligible voters who have not cast a ballot were sent a reminder by Helios a short while ago including their ballot information and links to vote.
If you have not received a ballot and expect to please email psf-elections(a)python.org As Soon As Possible.
-Ee W. Durbin III
Director of Infrastructure
Python Software Foundation
Greetings!
It seems I am unable to create PRs for 3.9. I've tried opening one directly, and I've tried using the needs-backport label.
Any ideas what I'm doing wrong?
--
~Ethan~
Hi!
It would be super helpful if core devs promoted several fundraising efforts
the PSF has going on. As core developers, your persuasion carries a
different weight - a more significant weight. Feel free to share tweets,
send emails to your organizations, share at virtual events, etc. Adding a
personal story to your shares makes it even more impactful.
*What initiatives are happening?*
1. End-of-the-year fundraiser
1. Fundraiser home page:
https://www.python.org/psf/donations/2020-q42020-drive/
2. Infographics you can use on your social media:
https://www.dropbox.com/sh/8ruk3on2yjazqoi/AACgrlv1c0XT5ExVJ56B9IKka?dl=0
3. email that went out to psf-community@ about this
<https://mail.python.org/pipermail/psf-community/2020-December/000843.html>
2. GitHub sponsors
1. Helps us getting recurring monthly donation:
https://github.com/sponsors/python
3. New PSF Sponsorship program
1. https://www.python.org/psf/sponsorship-new/
2. We just launched this last week
*Why is this important? (keeping to the point): *
- The PSF is not going to reach its expected revenue in 2020 nor 2021.
It could equate to a loss of $1.2M in expected revenue.
- Anything we raise will help offset that and will help us:
- preserve our financial reserve
- fund current operations
- help the PSF figure out new revenue streams in the meantime
- fund someone to address the backlog of open issues and unmerged PRs
ASAP
Email me if you have any questions. I will put out a blog next week to
expand more on the "Why is this important" section if you are looking to
read more on the subject.
Thank you,
Ewa
-----------------------
*Support the PSF during its end-of-the-year fundraiser:
https://www.python.org/psf/donations/2020-q42020-drive/
<https://www.python.org/psf/donations/2020-q42020-drive/>! With PyCon US
2020 & 2021 happening virtually, the PSF is faced with losing lots of
expected revenue. Donating now is more important than ever.*
It's starting to get very cold (at least on the Northern hemisphere) so we
have been carefully packaging a total of three new Python releases to keep
you warm these days!
Python 3.9.1 is the first maintenance release of Python 3.9, and also the
first version of Python to support macOS 11 Big Sur natively on Apple
Silicon. Go get it here:
https://www.python.org/downloads/release/python-391/
Maintenance releases for the 3.9 series will continue at regular bi-monthly
intervals, with **3.9.2** planned for Monday, 2021-02-08.
Python 3.10a3 is the third alpha release of Python 3.10. You can get it
here:
https://www.python.org/downloads/release/python-3100a3/
Python 3.10a3 is the release preview of the next maintenance release of
Python 3.8. You can get it here:
https://www.python.org/downloads/release/python-387rc1/
Assuming no critical problems are found prior to **2020-12-21** , the
currently scheduled release date for **3.8.7** , no code changes are
planned between this release candidate and the final release. That being
said, please keep in mind that this is a pre-release of 3.8.7 and as such
its main purpose is testing.
Your friendly release team,
Ned Deily, Steve Dower, Pablo Galindo, Łukasz Langa