[python-committers] Re: IMPORTANT: Python 3.10b2 release blockers

On Fri, May 28, 2021 at 6:55 AM Tim Peters wrote: > I suppose I could ask why heap types were fiddled to point to their > module objects too - but that's really got nothing to do with getting > the release done, so I won't :-) PyHeapTypeObject.ht_module was added by the PEP 573 "Module State

[python-committers] Re: Vote on core-dev chat choice

Your poll has a choice: "IRC channel other than #python-dev". FYI buildbot notifications already moved from #python-dev to #python-dev-notifs. I created a PR to move GitHub notifications there as well: https://github.com/python/psf-salt/pull/209 Victor On Sun, May 23, 2021 at 1:08 AM Senthil

[python-committers] Re: Trouble bisecting

Hi I'm always confused by expressions "good" and "bad". Previously, I added shell comments: $ git bisect bad # slow $ git bisect good # fast or: $ git bisect bad # no leak $ git bisect good # leak where good = leak is counter-intuitive... Since it confused too many people (including myself),

[python-committers] Re: Delete bpo spammer user

Hi Terry, When I detect a spam on bugs.python.org: * I remove the "User" role of the author * I unlink messages from the issue and then mark them as spam Victor ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an

[python-committers] Re: [Release manager team communication] master blocked until 3.10 beta 1 is released

Hi, Please don't attempt to merge PRs until the GitHub issue described below is solved ;-) Pablo renamed the default "master" branch to "main" (in a live Twitch stream ;-)) but got a GitHub internal error! Maybe it's because the dialog announced that 1.4k+ pull requests and 700+ repositositories

[python-committers] Re: Call for resumes: Developer-in-Residence to support CPython

Hi Ewa, This is really awesome! It's great that the PSF can now hire someone for that! The job offer is great, but I would like some clarification :-) (While I was part of the previous Steering Council who helped to write the job offer, sadly I was not avaialble last months when it was

[python-committers] Re: How can I ignore email notifications on commits mentioning my GitHub handle on CPython forks?

On Tue, Apr 6, 2021 at 6:41 PM Pablo Galindo Salgado wrote: > I think this is a good motivation to use > https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/automatically-merging-a-pull-request > instead as you can write your own commit message there and schedule the

[python-committers] Re: NOTE: Python 3.9.3 contains an unintentional ABI incompatibility leading to crashes on 32-bit systems

Hi, About this very specific ABI issue, one long term solution would be to exclude the PyThreadState structure from the C API, to not rely on it the ABI level. I started to add getter functions in Python 3.9: PyThreadState_GetInterpreter(), PyThreadState_GetFrame() and PyThreadState_GetID(). I'm

[python-committers] How can I ignore email notifications on commits mentioning my GitHub handle on CPython forks?

ject. Example: https://github.com/zooba/cpython/commit/9a5e643483578c3a944ceb5aa511d6c24280aedc "You are receiving this because you were mentioned." Some email headers: - From: Anthony Sottile To: "zooba/cpython" Cc: Victor Stinner , Mention Reply-To: "

[python-committers] Re: [Python-Dev] Re: [Release management] schedule for renaming the default branch

Hi Serhiy, On Thu, Mar 11, 2021 at 8:33 AM Serhiy Storchaka wrote: > I have above 200 feature branches in my local repository. Will renaming > the master branch cause any problems? I don't think that you need to do anything on your machine nor on your open PRs. When I use "git switch -c

[python-committers] Re: Accepting PEP 597 (Add optional EncodingWarning)

Congratulation INADA-san! I'm impressed by your tenacity :-) Last months, I followed your different propositions on discuss.python.org to use UTF-8 by default in Python. It's good to see the first non-controversial part being accepted! I hope that this PEP will help to move towards a world where

[python-committers] Re: Publish better than md5sums of Python builds?

On Tue, Mar 16, 2021 at 9:16 PM Gregory P. Smith wrote: > The benefit of listing the sha256 for files is that it prevents this question > coming up again and again because md5 is old and rightfully on the "never > use" list for many people. Even if there are situations where it is fine as > an

[python-committers] Re: Ken Jin got the bug triage permission

Oh, I recognize his GitHub nickname. He fixed a few bugs that I introduced and helped me on some issues. Congrats Ken Jin! Victor On Sun, Apr 11, 2021 at 7:31 PM Pablo Galindo Salgado wrote: > Hi everyone, > > I started to mentor Ken Jin (Fidget-Spinner on Github) and I gave him bug > triage

[python-committers] Re: How can I ignore email notifications on commits mentioning my GitHub handle on CPython forks?

Oh, there is an update! 3 days ago, a member of the GitHub "staff" wrote: "This should be fixed. Please do let us know if it is not." https://github.community/t/i-am-getting-notifications-due-to-being-mentioned-in-a-commit/172531/32 Victor On Tue, Apr 6, 2021 at 4:36 PM V

[python-committers] Re: PEP 563 and Python 3.10.

Hi, In this case, we need more advanced warnings filters to only show deprecation warnings in the "current application code", and ignore deprecation warnings from any other module. Is there a way to create an entry point in setuptools which says "this application uses the package xxx"? Since

[python-committers] Re: PEP 563 and Python 3.10.

On Wed, Apr 21, 2021 at 1:24 PM M.-A. Lemburg wrote: > Isn't that an educational problem ? Adjusting reporting of > warnings isn't all that hard: A common practical problem is a project CI which pulls the most recent verisons of 3rd party dependencies and suddenly break if a new deprecation

[python-committers] Re: Submit PEP 624 to SC.

You can write an email to Python Steering Council . There is also: https://github.com/python/steering-council/ Victor On Sat, Feb 13, 2021 at 3:02 AM Inada Naoki wrote: > > Hi, all. > > I think PEP 624 is ready to SC review for now. > How can I submit it to the SC? > > Regards, > -- > Inada

[python-committers] Re: What is github trying to tell me?

Hi Eric, The bot source code and bug tracker can be found at: https://github.com/python/miss-islington Victor ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org

[python-committers] Re: Welcome Ammar Askar to the team!

Welcome aboard Ammar! I worked with Ammar in various places of Python which is a good sign. He is curious to enhance many things and he was already very helpful! I was in holiday last weeks. Since the vote is closed, I cannot vote anymore, but I don't care and I vote +1 for his promotion anyway

[python-committers] Re: Roundup to GitHub Issues migration

Hi Ezio, What is the status of the migration of Python issues from bugs.python.org (Roundup) to GitHub? Is it still a work-in-progress or is it stalled? Victor On Mon, Jun 21, 2021 at 4:20 AM Ezio Melotti wrote: > > As you might know, PEP 581 (Using GitHub Issues for CPython) has been >

[python-committers] Re: Proposed tiered platform support

Hi Brett, You can put my name as Contact of all Fedora and RHEL platforms. Note: Fedora "Rawhide" is the rolling release and it's common that these buildbots are broken by kernel, compiler or glibc updates, rather than actual Python regressions. Time to time, it detects real Python regressions.

[python-committers] Re: Python 3.11.0a6 is blocked

By the way, AMD64 Arch Linux Usan 3.x started failing because I enabled more tests on this buildbot yesterday. Previously, "test_faulthandler test_hashlib test_concurrent_futures test_ctypes" were simply skipped on this UBSAN buildbot. I'm working on fixing the 3 failing tests: test_ctypes,

[python-committers] Re: Please turn on 2FA/MFA support on your GitHub account

When I propose a PR on a project and I don't plan to contribute more than than PR, when the PR is merged, I delete my fork. At work, I send patches to many different projects to fix some Python 3.11 compatibility issues. It just was a general remark. If you enable 2FA on GitHub, the effect is not

[python-committers] Re: Proposed tiered platform support

I dislike the Tier 1 rule "All core developers are responsible to keep these platforms, and thus ``main``, working." In my experience, "Everyone is reponsible" means in practice "nobody is responsible". IMO you must also put two names in front of each platform. Otherwise, nobody will fix them

[python-committers] Re: Proposed tiered platform support

Ok, I added myself on the PR. Victor ___ 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

[python-committers] Re: Proposed tiered platform support

On Fri, Mar 25, 2022 at 7:04 PM Brett Cannon wrote: > > On Fri, Mar 25, 2022 at 4:23 AM Victor Stinner wrote: >> >> I dislike the Tier 1 rule "All core developers are responsible to keep >> these platforms, and thus ``main``, working." >> >> In

[python-committers] Re: Proposed tiered platform support

On Fri, Apr 1, 2022 at 12:25 AM Brett Cannon wrote: > powerpcle-linux-gnu glibc, clang This one has 2 core devs in the PR: "Petr Viktorin, Victor Stinner". > s390x-linux-gnu glibc, gcc > s390x-linux-gnu glibc, clang > x86_64-unknown-freebsd BSD libc, cc (Victor is alre

[python-committers] Re: Proposed tiered platform support

On Fri, Apr 1, 2022 at 1:42 AM Victor Stinner wrote: > > On Fri, Apr 1, 2022 at 12:25 AM Brett Cannon wrote: > > powerpcle-linux-gnu glibc, clang > > This one has 2 core devs in the PR: "Petr Viktorin, Victor Stinner". Oh wait, "Petr Vikt

[python-committers] Consider adding a Tier 3 to tiered platform support

Hi, I don't think that the current PEP 11 draft (*) describes correctly the current status of a bunch of platforms which are not "actively" supported. I like to call these plaforms as "best effort support" platforms. I propose considering adding an explicit "Tier 3" to PEP 11. (*)

[python-committers] Re: Consider adding a Tier 3 to tiered platform support

I like your proposal better than mine :-) I agree that my Tier 3's constraints were too weak :-( On Fri, Apr 1, 2022 at 9:22 PM Brett Cannon wrote: >> For me the main threat of (adding a platform to) Tier 3 is the risk >> that we might never ever able to drop support for these platforms. PEP >>

[python-committers] Re: Consider adding a Tier 3 to tiered platform support

On Fri, Apr 1, 2022 at 11:19 PM Christian Heimes wrote: > How about: > > * a buildbot is required. For a transition period a public CI system, > that runs Python's test suite at least once per day, is also acceptable. > > * at least one active contributor who acts as a point of contact, >

[python-committers] Re: Proposed tiered platform support

You wrote that you want at least 2 core devs responsible for each tier 1 platform. I didn't understand if this requirement is also for Tier 2. Who are these core devs? Is there a list? Victor ___ python-committers mailing list --

[python-committers] Re: Please turn on 2FA/MFA support on your GitHub account

On Tue, Feb 8, 2022 at 12:11 AM Brett Cannon wrote: > And to be clear, you only need access to your 2FA solution when you log in; > it's not a day-to-day action at all (I personally have not used my 2FA since > the last time I logged into a new device for the first time or when my GitHub >

[python-committers] Re: Python 3.11.0a4 is blocked

On Thu, Jan 6, 2022 at 12:33 PM Pablo Galindo Salgado wrote: > * https://bugs.python.org/issue46006 > > Victor made a revert of his PR but unfortunately, we cannot easily backport > it to 3.10 as it affects the ABI. It affects the interpreter state structure > that although is not on the stable

[python-committers] Re: [IMPORTANT] Preparations for 3.11.0 beta 1

On Thu, Apr 7, 2022 at 5:35 AM Inada Naoki wrote: > I just submitted the PEP 686 to the SC. > https://github.com/python/steering-council/issues/118 > > In this PEP, I am proposing: > > a. Small improvement for UTF-8 mode in Python 3.11 > b. Make UTF-8 mode default in Python 3.13. It's easier to

[python-committers] Re: [IMPORTANT] Preparations for 3.11.0 beta 1

IMO adding locale.getencoding() to Python 3.11 is not controversial and is useful even if PEP 686 is rejected. This function was discussed for 1 year (bpo-43510, bpo-43552, bpo-43557, bpo-47000) and there is an agreement that there is a need for this function. > Making `open(path,

[python-committers] Pablo Galindo Salgado got bug triage permission, mentored by Victor

Hi, To recognize the good contributions of Pablo Galindo Salgado, I gave him the bug triage permission on bugs.python.org. Pablo already got 8 commits merged into master since September 2017. He is working on non-trivial topics like designing an API to expose posix_spawn() in the os module:

Re: [python-committers] [Python-Dev] Slipping Python 3.5.5rc1 and 3.4.8rc1 because of a Travis CI issue--can someone make Travis CI happy?

I created an issue with more information: https://bugs.python.org/issue32620 Victor 2018-01-22 11:33 GMT+01:00 Larry Hastings : > > > I have three PRs for Python 3.5.5rc1: > > https://github.com/python/cpython/pull/4656 > https://github.com/python/cpython/pull/5197 >

Re: [python-committers] Official way to check out a tag?

2018-01-23 11:29 GMT+01:00 Antoine Pitrou : > Did you try "make distclean"? Oh by the way, it took me year to discover the cool *builtin* Git function: * "git clean -ndx" shows all untracked files and directories * "git clean -fdx" removes all untracked files and directories

Re: [python-committers] AppVeyor is now required to pass on PRs

Hi, AppVeyor usually takes between 30 min and 1 hour to check a PR, whereas Travis CI takes between 10 and 20 minutes (in average, ignoring rare cases when it's broken). AppVeyor queue is regulary busy. Sometimes, I know that my PR is right, because the fix is obvious. Sometimes, the PR has no

[python-committers] Current Travis CI "job backlog incident"

Hi, FYI Travis CI is sick tonight: https://www.traviscistatus.com/ Jan 17, 00:26 UTC : Update - We are still investigating the job backlog incident. Victor ___ python-committers mailing list python-committers@python.org

[python-committers] Mentoring and promoting contributors (was: Let's give commit privileges to Nathaniel J. Smith)

Hi, 2018-01-25 0:29 GMT+01:00 Eric V. Smith : > +1. I actually thought [Nathaniel Smith] was a committer already. By the way, if you notice an active contributor is good candidate to become a core dev in the long term, you may start the process that I described here:

Re: [python-committers] AppVeyor is now required to pass on PRs

Hi, The best would be able to have a bot merging a pull request once tests pass and a core developer asked a merge. I'm not talking about the current approval using review, but something new, like adding a special comment like "Merge". Such comment would only merge if it's written by a core

Re: [python-committers] Requirements to get the "bug triage" permission?

2018-01-25 15:18 GMT+01:00 Jesus Cea <j...@jcea.es>: > On 06/12/17 23:17, Victor Stinner wrote: >> My problem is that we don't have a long list of "awards" in Python: >> the triage bit and the commit bit... >> >> I had some ideas to create badges, but be

Re: [python-committers] ssl module will require OpenSSL 1.0.2

2018-01-26 23:09 GMT+01:00 Christian Heimes : > OpenBSD is still supported. But you either have to install OpenSSL, live > without SSL support or get LibreSSL fixed. Python's test suite is > passing without ssl available. (Sure, if LibreSSL is fixed, the issue goes away, but

Re: [python-committers] ssl module will require OpenSSL 1.0.2

2018-01-26 20:47 GMT+01:00 Christian Heimes : > LibreSSL does not yet implement these APIs yet Does it mean that Python 3.7 will not support OpenBSD anymore? Well, it's not like OpenBSD support is perfect, but there are only few issues on OpenBSD. Does other operating

Re: [python-committers] ssl module will require OpenSSL 1.0.2

2018-01-26 23:25 GMT+01:00 Christian Heimes : > We never officially supported LibreSSL, so we aren't breaking any > promise. I supported LibreSSL as a best-effort approach. > > You can still have TLS support with extra packages. Python requests and > pip can also use

Re: [python-committers] core developer status

Hi Xavier, I am really sad to read this email, but well, you have your reasons. I wanted to thank you for your numerous contributions to pdb, Android support, enhancement of the build system, bugfixes, etc. Thanks to you, we are now very close to have a full support of Android, basically the

Re: [python-committers] Results of Pablo's promotion votes: Pablo is promoted as a core dev!

Hi, 2018-06-19 19:43 GMT+02:00 Victor Stinner : > The result of the vote to to promote Pablo Salingo Salgado as core developer > after one week is positive: I declare that Pablo is now a core developer, > congrats! (...) > > Giving more responsibilities to Pablo is part of the l

Re: [python-committers] Results of Pablo's promotion votes: Pablo is promoted as a core dev!

2018-07-31 18:47 GMT+02:00 Brett Cannon : > I just wanted to say thanks for thinking about this to begin with. It's very > easy to set a new core dev loose and forget what it takes to get up and > running. I like the idea of putting one mentor per newly promoted core developer. IMHO it reduces

Re: [python-committers] View logs on VSTS?

Hi, The error may be related to https://bugs.python.org/issue33782 I understood that VSTS has troubles when a PR gets a new commit while VSTS is running tests on the previous commit. Victor 2018-08-02 0:00 GMT+02:00 Antoine Pitrou : > > Hello, > > I may be missing something, but I fail to view

Re: [python-committers] Reminder of BDFL succession timeline + CFP

2018-08-01 23:10 GMT+02:00 M.-A. Lemburg : > So let's ponder some more about ideas we could use to > get there and perhaps watch some Monty Python movies for > inspiration ;-) Monty Python's Life of Brian is an obvious tutorial how to select a BDFL where FL means for life ;-) Victor

Re: [python-committers] MSDN Subscriptions/Renewals

Steve wrote: > Just to clarify one thing: you don't need a special license to get Visual Studio Community Edition to work on Python, even within a big company - it's free for open source work, and has everything we need. My employer gave me a laptop without Windows license. It is likely the case

Re: [python-committers] Winding down 3.4

> "shutil copy* unsafe on POSIX - they preserve setuid/setgit bits" > https://bugs.python.org/issue17180 There is no fix. A fix may break the backward compatibility. Is it really worth it for the last 3.4 release? > "XML vulnerabilities in Python" > https://bugs.python.org/issue17239 Bug

Re: [python-committers] Proposal on how to vote (was: An alternative governance model)

I hate cabals. I prefer to keep everything open and transparent, as this mailing list is public (even if only core developers are allowed to post). Which drawback do you see of making the votes public? Victor 2018-07-19 0:26 GMT+02:00 Antoine Pitrou : > > By the way, should the vote be public

Re: [python-committers] Proposal on how to vote (was: An alternative governance model)

2018-07-19 0:36 GMT+02:00 Antoine Pitrou : > Let's say I'm being asked if X should be a « next BDFL » (or Council > member, etc.) and I vote no publicly. What is my position if X is > elected? How will my vote be interpreted? Will I get discriminated > against (even unconsciously) just because

[python-committers] And Now for Something Completely Different

or: Replace Dictatorship with Democracy. Hi, == Introduction: unjustified fears? == I see that many people are eager to replace the old governance based on a single BDFL with a new governance with a new BD(FL) and/or a council. My problem is that I don't see any clear definition of the roles of

Re: [python-committers] And Now for Something Completely Different

Hi Ethan, Thanks for your feedback! 2018-07-20 2:51 GMT+02:00 Ethan Furman : >> I see that many people are eager to replace the old governance based >> on a single BDFL with a new governance with a new BD(FL) and/or a >> council. My problem is that I don't see any clear definition of the >>

Re: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

2018-07-20 22:42 GMT+02:00 Brett Cannon : > The leading proposal of a deadline to get governance model proposals in and > deciding on a voting procedure is October 1. Do you need more time than > that? And if so how much are you asking for? Carol wrote "Proposals due by Sept 9, 2018 AOE". I'm

Re: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

Please extend the deadline: next week, I will be at EuroPython (I don't think that I will have time to sit down and come up with something), and I'm (more or less) in holiday the whole month of August. Victor 2018-07-19 21:43 GMT+02:00 Antoine Pitrou : > > Le 19/07/2018 à 21:35, Carol Willing a

Re: [python-committers] And Now for Something Completely Different

2018-07-20 18:32 GMT+02:00 Steven D'Aprano : > What happens when two trusted experts disagree and the voters don't have > the expertise to tell which one is correct? In my proposal, if no consensus can be found, the vote fails to reach the majority, the PEP is rejected. Usually, people disagree

Re: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

2018-07-21 0:58 GMT+02:00 Mariatta Wijaya : > Oct 1: Deadline for people to come up with proposals of governance model, > candidates, and how to vote > Dec 1: Deadline to choose a governance model, (and if possible, we choose > the new leader(s) too) What happens between October and December?

Re: [python-committers] And Now for Something Completely Different

Brett: > This will also make it harder to become a core developer. In the past we > have been willing to give people commit privileges for showing they know how > to code to our standards, make decisions when it came to PRs, and knew when > they were outside of their depth (e.g. giving someone

Re: [python-committers] Language moratorium

Hi, 2018-07-18 18:11 GMT+02:00 Stefan Krah : > Perhaps we could have one again, say for 12 months so we can figure things > out. Other Python implementations may welcome the moratorium so they can > catch up. Python 3.8 has a new syntax for assignment expressions (PEP 572). A moratorium of 12

[python-committers] Identify roles of the BDFL

Hi, 2018-07-12 19:12 GMT+02:00 Mariatta Wijaya : > What is the role of the successor(s)? Do we assume "whatever Guido did", or > is this an opportunity to come up with a new process? > > One useful resource is Vicky Brasseur's talk: Passing the Baton, Succession > planning for your project

Re: [python-committers] Transfer of power

Hi, 2018-07-12 16:57 GMT+02:00 Guido van Rossum : > Now that PEP 572 is done, I don't ever want to have to fight so hard for a > PEP and find that so many people despise my decisions. Thank you for having solved the long standing issue of the PEP 572: taking a decision was the only way to stop

Re: [python-committers] Welcoming Petr Viktorin as our newest core developer :)

Congrats Petr, welcome aboard! Victor ___ 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] Idea: Create subteams?

Hi, While thinking about how to get more contributors onboard, I identified that one bottleneck is building trust. Currently, a vote to promote a contributor as a core dev requires the approval of almost all active core developers, and this list is quite large (50 people? more?). It takes a lot

Re: [python-committers] Idea: Create subteams?

to fix the doc, whereas they misunderstood something and the doc was plain right :-) Victor 2018-04-26 16:31 GMT+02:00 Yury Selivanov <yselivanov...@gmail.com>: > On Thu, Apr 26, 2018 at 10:12 AM Victor Stinner <vstin...@redhat.com> wrote: > [..] >> I ident

Re: [python-committers] A different way to focus discussions

It seems like the PEP 572 discussions restarted on python-dev mailing list with more than 100 emails in one week. Stupid idea: we created a mailing list just to fix os.random(): PEP 522 and PEP 524, whereas these discussions were not the ones with the most emails. Why not creating a new pep572

Re: [python-committers] PEP 8015: Organization of the Python community

Le lun. 15 oct. 2018 à 11:35, Antoine Pitrou a écrit : > > I don't want to put this responsibility on the board. So yes, > > conflicts between core developers will be handled by the conduct WG. > > How does that work? The conduct WG doesn't even seem to have published > procedures. Also we

Re: [python-committers] discuss.python.org participation

Le sam. 20 oct. 2018 à 01:58, Larry Hastings a écrit : > I'll also admit I've been dragging my feet about setting up > yet-another-online-account for yet-another-form-of-online-communication. > (But this time! It'll solve all our problems! Finally, our conversational > deliverance is at

Re: [python-committers] Moderation of the Python community

Le mer. 17 oct. 2018 à 21:09, Donald Stufft a écrit : > Honestly, I think an independent group managing these issues is the right way > to handle them. I’m loathe to bring it up because the situation was a long > time ago, and has been resolved, but I’ve personally had to engage the CoC >

Re: [python-committers] Moderation of the Python community

Oh, by the way, should we have two different choices: remove the commit bit from a core dev (downgrade a core dev as a regular contributor) and ban a core dev? Victor Le jeu. 18 oct. 2018 à 00:03, Victor Stinner a écrit : > > Le mer. 17 oct. 2018 à 21:09, Donald Stufft a écrit : > >

Re: [python-committers] Moderation of the Python community

Ok, I proposed an update to my PEP to explain the process to ban a core developer: https://github.com/python/peps/pull/810/files Victor Le jeu. 18 oct. 2018 à 01:23, Victor Stinner a écrit : > > Le jeu. 18 oct. 2018 à 00:16, Ethan Furman a écrit : > > > > On 10/17/2018 03:05

Re: [python-committers] Moderation of the Python community

Le jeu. 18 oct. 2018 à 00:16, Ethan Furman a écrit : > > On 10/17/2018 03:05 PM, Victor Stinner wrote: > > > Oh, by the way, should we have two different choices: remove the > > commit bit from a core dev (downgrade a core dev as a regular > > contributor) and ban a cor

Re: [python-committers] discuss.python.org participation

Le mer. 17 oct. 2018 à 03:56, Ethan Furman a écrit : > I also supported the trial of Discourse. > > However, now that I have tried it, it will be a no from me. I find the > presentation of threaded conversations in linear format to be confusing, > figuring out what I have and have not read to be

[python-committers] Moderation of the Python community

Hi, I see more and more discussions about the moderation of the Python community. There is a PSF "conduct" Working Group: https://wiki.python.org/psf/ConductWG/Charter I noticed the following questions: * Lack of transparency on how moderation is decided * Lack of transparency on the number of

Re: [python-committers] Moderation of the Python community

Le mer. 17 oct. 2018 à 16:06, Tim Golden a écrit : > On 17/10/2018 15:03, Victor Stinner wrote: > > Moreover, the Code of Conduct should be seen as > > a way to evict a core developer out of Python. > > I'm assuming you missed a "not" in that last sentence? (Oops,

Re: [python-committers] PEP 8015: Organization of the Python community

Hi, To take in account all discussions around my PEP 8015, I updated it: it’s now the version 4. I added a Version History at the bottom of the PEP to help reviewers. In short: votes are now announced in advance (0, 1 or 3 weeks depending on the vote) and only open for 1 week instead of 1 month,

Re: [python-committers] PEP 8015: Organization of the Python community

Hi Brett, I just updated my PEP to take in account your comments. Le ven. 12 oct. 2018 à 20:33, Brett Cannon a écrit : >> Team members are Python contributors and Python core developers. The >> team is responsible to select who can join the team and how. > > How is this bootstrapped? Do I get

Re: [python-committers] If you care about the voting method, please vote ; -)

Le ven. 2 nov. 2018 à 23:49, Steven D'Aprano a écrit : > How many people voted? Out of what (approximate) pool of potential > voters? 25 voters on 65 core developers who have an account on discuss.python.org. 25 can be seen at:

Re: [python-committers] Timeline to vote for a governance PEP

Le sam. 3 nov. 2018 à 04:40, Eric Snow a écrit : > Would it help if we only published who voted, and kept their votes private? > Publishing the actual votes probably doesn't make a big difference here, > relative to the broader Python/tech community. The PEP has a whole section explaining the

[python-committers] Timeline to vote for a governance PEP

Hi, According to the PEP 8001: "The vote will happen in a 2-week-long window from November 16 2018 to November 30 (Anywhere-on-Earth)." It's now in less than two weeks. I see that the PEP 8001 is still being updated (voting method). Should we still expect new changes before the vote starts? Can

Re: [python-committers] Timeline to vote for a governance PEP

> > I see that the PEP 8001 is still being updated (voting method). Should > > we still expect new changes before the vote starts? > > I don't detect any groundswell of opposition anymore now that the > voting method changed. I'm unhappy with the "[] Further discussion" choice. We have a

Re: [python-committers] Suggestion: A PSF grant for running a "Core Dev Mentorship Program"

Le ven. 2 nov. 2018 à 14:55, Antoine Pitrou a écrit : > As a side note, I'm not against the general principle of funding some > mentorship or other contribution-related activity. I'm just unsure that > this would be money well spent. This is a good question. We already a lot of core developers,

Re: [python-committers] Suggestion: A PSF grant for running a "Core Dev Mentorship Program"

Le 02/11/2018 à 14:19, Tal Einat a écrit : > > I am learning that > > effectively mentoring a developer requires being able to spend a good > > amount of time nearly daily on such mentoring. It really depends on the availability and skills of the mentoree. I have mentorees who are very busy and

Re: [python-committers] PEP 8015: Organization of the Python community

Brett: > Is this here to mean the expectation that the conduct WG will manage CoC > issues for the core development team? Core developers and Steering Committee members are at the same level than any other Python contributor when they misbehave. I expect the "autonomous" conduct workgroup to

Re: [python-committers] Timeline to vote for a governance PEP

Le sam. 3 nov. 2018 à 10:39, Antoine Pitrou a écrit : > > I'm unhappy with the "[] Further discussion" choice. We have a > > governance crisis. Many people would like to see it resolved as soon > > as possible, I don't see the ability to vote for "[] Further > > discussion" as a way to resolve

Re: [python-committers] Timeline to vote for a governance PEP

Le jeu. 15 nov. 2018 à 23:51, Paul Moore a écrit : > No, I'm uncomfortable with the discussion period overlapping the > voting period, because the fact that you can't change your vote means > that once someone votes, there's no incentive to continue discussing. > But I accept that it's how it's

[python-committers] Comparison of the 7 governance PEPs

Hi Paul, Le sam. 3 nov. 2018 à 11:55, Paul Moore a écrit : > Currently, I feel like my only option is to abstain and hope - I don't > have the time (or knowledge) to review, understand and assess the > proposals well enough to make an informed vote, but I have no way of > assessing the "expert

Re: [python-committers] IMPORTANT: Missing Email Addresses for Governance Election Voter Roll

I'm not sure about Roundup. In the web UI, the email address is partially hidden for me. I'm not a Roundup Admin. Le mar. 6 nov. 2018 à 13:24, Donald Stufft a écrit : > If roundup has an API, feel free to submit a PR to generate-voter-roll.py in > that same repository to have it pull from

Re: [python-committers] PEP 8015: Organization of the Python community

s (instead of a limit of 2 mandates: 6 years in total), and a committee member can now be a PEP delegate. Full text below. HTML version: https://www.python.org/dev/peps/pep-8015/ PEP: 8015 Title: Organization of the Python community Author: Victor Stinner Status: Active Type: Informational Co

Re: [python-committers] Timeline to vote for a governance PEP

Le sam. 3 nov. 2018 à 03:37, Victor Stinner a écrit : > According to the PEP 8001: "The vote will happen in a 2-week-long > window from November 16 2018 to November 30 (Anywhere-on-Earth)." It's > now in less than two weeks. It seems like the vote is going to start tomorrow,

Re: [python-committers] Please wait for my governance PEP

th one of them. You can reach out to Mariatta or Barry to learn how far > along they are. > > I know I'd be very happy to have you help with PEP 8012 :-) > > -- > Best regards, > Łukasz Langa > > > On Oct 4, 2018, at 15:02, Victor Stinner wrote: > > Hi, > >

Re: [python-committers] Please wait for my governance PEP

I published my PEP as the PEP 8015: Organization of the Python community. Victor Le jeu. 4 oct. 2018 à 15:02, Victor Stinner a écrit : > > Hi, > > I was waiting for other governance PEPs to decide if I would write > mine or not. Since I don't see other PEPs, I decided that I wi

Re: [python-committers] python-committers is dead, long live discuss.python.org

and to python-committers... And now we can enjoy discussions splitted between the two :-) Victor Le sam. 29 sept. 2018 à 09:50, M.-A. Lemburg a écrit : > > On 29.09.2018 03:21, Barry Warsaw wrote: > > On Sep 28, 2018, at 15:03, Victor Stinner wrote: > > > >> It seem

Re: [python-committers] python-committers is dead, long live discuss.python.org

Le ven. 28 sept. 2018 à 23:46, Łukasz Langa a écrit : > - go to https://discuss.python.org/ and create your account there; It seems like anyone can subscribe. Is the Committer group reserved to core developers? If yes, how do you know which accounts are linked to core developers? Oh, I just saw

Re: [python-committers] 1 week to Oct 1

Le jeu. 27 sept. 2018 à 01:28, Mariatta Wijaya a écrit : > Really sorry folks, but I also would like to request an extension, by one > week to Oct 8. The PEP 8000 lists 5 governance PEPs: """ PEPs in the 8010s describe the actual proposals for Python governance. It is expected that these PEPs

Re: [python-committers] 1 week to Oct 1

> The PEP 8000 lists 5 governance PEPs: Oops, there are even 6 governance PEPs :-) Victor ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct:

<    1   2   3   4   5   >