> ## People who are in the developer log but have never made a change
> 7. Carl Friedrich Bolz: 2011-03-21 for PyPy compatibility
He got 2 commits merged into master this month ;-) Better late than never!
Victor
___
python-committers mailing list -- pyt
Hi,
To create a 3.5 backport, I use the following commands (something like
this, adapt names ;-):
cd ~/python/3.5
git checkout -b fix_something35
git cherry-pick -x commit_sha1
# maybe fix conflicts or make further changes
make
./python -m test -v test_modified_test
# or better:
Le 19/08/2019 à 17:51, Abhilash Raj (maxking) a écrit :
I asked to remove this label since it was misused by contributors who
are not aware that 3.5 not longer accept bug fixes.
Ah okay, I was just looking for this. I guess it makes sense, but I always
thought non core devs can't add labels.
Hi,
Le 21/08/2019 à 19:38, Mariatta a écrit :
We have a new Python triage team on GitHub to help improve our workflow.
GitHub has a nice table that shows what a triager can or cannot do in
general:
https://help.github.com/en/articles/repository-permission-levels-for-an-organization#repository
Hi,
Dong-hee Na got the bug triage permission:
https://github.com/python/core-workflow/issues/357
The bug triage permission now means being able to close issues at
bugs.python.org, but also close pull requests and add labels on pull
requests on GitHub (but not to merge a PR).
I am mentoring him
Hi,
I see a high activity on pull requests on the CPython project, likely
because of the CPython sprint. Sadly, the AppVeyor is still slow and
still has only 2 jobs in parallel.
Would it be possible to make the AppVeyor job non-mandatory to allow
to merge a PR faster? If it's configurable per bra
Le lun. 9 sept. 2019 à 18:46, Benjamin Peterson a écrit :
> No one could think of a reason not to replace AppVeyor with Azure, so I've
> gone ahead and done that on all those branches.
Here is a reason to not replace AppVEyor with Azure:
https://bugs.python.org/issue37245
The macOS job of Azure
Hi Brett,
Le jeu. 12 sept. 2019 à 18:54, Brett Cannon a écrit :
> https://devguide.python.org/developers/ has been updated to use a CSV
> generated from the python-core.toml file using code found in that repository.
> This should make maintaining that page in the devguide much easier and make
You have one week to vote at:
https://discuss.python.org/t/vote-to-promote-joannah-nanjekye-as-a-core-dev/2347
Victor
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
ht
lun. 16 sept. 2019 à 14:53, Victor Stinner a écrit :
>
> You have one week to vote at:
> https://discuss.python.org/t/vote-to-promote-joannah-nanjekye-as-a-core-dev/2347
>
> Victor
___
python-committers mailing list -- python-committer
Hi,
The PEP 13 says "A new council is elected after each feature release."
Does it mean that we need elect a new Steering Council before/after
Python 3.8.0 final release which is scheduled at 2019-10-21 (in more
or less one month)?
If a vote is organized, when should "Candidates advertise their
i
Congrats Joannah! You deserve this promotion ;-)
As I wrote in the vote, I will mentor Joannah one more month to help
her to deal with her new responsibilities. Usually, I ask to validate
with me before merging a PR.
Note: I'm not sure if she is already subscribed to the
Victor
Le mer. 25 sept.
Hi Łukasz,
Le lun. 30 sept. 2019 à 16:32, Łukasz Langa a écrit :
> > On 30 Sep 2019, at 16:09, Nick Coghlan wrote:
> >
> > I've filed https://bugs.python.org/issue38326 as a release blocker, as
> > I don't think we should be cutting RCs when changes have been made to
> > a PEP-approved API witho
I saw you fixing dozens of tarfile issues last years. Thanks for all
the work you did for Python!
Victor
Le mar. 3 déc. 2019 à 16:33, Lars Gustäbel a écrit :
>
> Hi!
>
> My name is Lars Gustäbel. I am the author of the tarfile module, and I have
> been its maintainer for over ten years. I have n
If a core dev asks to have their commit bit removed, what happens if
they change their mind? Do we have go through the usual vote process?
Or should we just add it back whenever they ask?
Victor
Le mer. 4 déc. 2019 à 21:23, Brett Cannon a écrit :
>
> You ask me to do it. :) I have gone ahead and
Can you please open an issue at https://bugs.python.org/ and then post
the link in this thread?
Thanks in advance,
Victor
Le mar. 10 déc. 2019 à 14:18, Christian Tismer a écrit :
>
> Hi Łukasz,
>
> tonite I found a critical bug that affects all heaptype extension
> classes with a custom (not PyT
Le mer. 11 déc. 2019 à 01:00, Brett Cannon a écrit :
> We discussed the situation on the steering council and we are fine with
> making an exception for folks who felt caught off-guard asking Ernest to be
> added to the voter roll even though voting has already started.
>
> In the new year I wil
Congratulations to our bug triagger champion, Karthikeyan
Singaravelan! ;-) Thanks Andrew for promoting him.
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
python-committers mailing list -- python-committers@pytho
Hi,
Le ven. 31 janv. 2020 à 21:59, Pablo Galindo Salgado
a écrit :
> I have been mentoring Batuhan Taskaya ("BTaskaya" on BPO, "isidentical" on
> GitHub) for
> the past few months. We have been working closely together on some features
> as "ast.unparse",
> many bugfixes and documentation impro
Le mar. 18 févr. 2020 à 09:47, Steve Dower a écrit :
> Windows 7 is not supported for 3.9, but the buildbots have not been
> removed/repurposed yet. They can be ignored.
I created https://github.com/python/buildmaster-config/issues/168
"Disable Windows 7 on the Python 3.x branch".
Can someone p
Le mar. 18 févr. 2020 à 01:14, Łukasz Langa a écrit :
> - macOS (importlib) -
> https://buildbot.python.org/all/#/builders/275/builds/249
It's a regression of a change merged yesterday:
https://bugs.python.org/issue38691
> - Fedora (shutil and zipfile) -
> https://buildbot.python.org/all/#/bui
Le mar. 18 févr. 2020 à 19:42, Jason R. Coombs a écrit :
> The Fedora failures in shutil and zipfile are "no space left on device".
> Seems like an environment/infrastructure issue.
Did you see my email? I opened an issue for the Fedora and Windows failures.
> "test_shutil fails with OSError: [
FYI I'm using a Gmail filter to ensure that emails coming from
rep...@bugs.python.org are never marked as spam.
Victor
Le ven. 28 févr. 2020 à 20:51, Antoine Pitrou a écrit :
>
>
> Le 28/02/2020 à 19:56, Mariatta a écrit :
> > I think this is same issue
> > as https://github.com/python/bugs.pyth
Hi,
There is a new "CodeCov" thing on Python pull requests which adds a
giant comment with many numbers and statistics and then mark my pull
request as "failed" (red).
I know the concept of code coverage, ok. But who uses this service?
Does it *have to* send emails to say:
"Merging #18743 into m
https://discuss.python.org/t/vote-to-promote-dong-hee-na/3794
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-co
Hi,
tl; dr Maybe the 1090 pending pull requests will have to be rebased on
master to be able to be merged, unless we enhance our CI to always
test PRs after rebasing them on the master branch. I'm not sure at
this point.
--
FYI the Night’s Watch is still fixing the CIs in the darkness for you
:-
Reminder: the "Vote to promote Dong-hee Na" will close next tuesday
morning. So far, it got 21 voters.
Victor
Le mar. 31 mars 2020 à 01:48, Victor Stinner a écrit :
>
> https://discuss.python.org/t/vote-to-promote-dong-hee-na/3794
>
> Victor
> --
> Night gathers,
Oh sorry, the vote will close automatically *Wednesday* morning (in 2
days), not tomorrow morning.
Victor
Le dim. 5 avr. 2020 à 02:43, Victor Stinner a écrit :
>
> Reminder: the "Vote to promote Dong-hee Na" will close next tuesday
> morning. So far, it got 21 voters.
>
&
Le lun. 6 avr. 2020 à 13:31, Steve Dower a écrit :
> The CI configuration is loaded from the PR head, at least on GitHub
> Actions (where you can validate config changes in PR) and Azure
> Pipelines. I just validated this by re-running an old PR and watched it
> choose OpenSSL 1.1.1d instead of 1.
Welcome aboard Kyle! Congratulations for your promotion!
Victor
Le mer. 15 avr. 2020 à 03:38, Kyle Stanley a écrit :
>
> Thank you for the support everyone and for adding my permissions, Brett! I
> wrote my "acceptance speech" over on discuss:
> https://discuss.python.org/t/vote-to-promote-kyl
Antonio Cuni's slides:
"HPy: a future-proof way of extending Python?"
https://speakerdeck.com/antocuni/hpy-a-future-proof-way-of-extending-python
Guido, Pablo: are your slides public? (Guido sent a link but I didn't
know if it can be shared in public, moreover I lost the link :-))
Victor
Le mer.
Hi,
Thanks for the release!
Python 3.8.3rc1 has a compiler regression introduced after Python
3.8.2: https://bugs.python.org/issue39562#msg365311
I proposed different options to fix it:
https://bugs.python.org/issue39562#msg367018
Victor
Le jeu. 30 avr. 2020 à 01:08, Łukasz Langa a écrit :
>
Hi,
In the Python 3.8.3rc1 changelog, I see these two changes:
(1) bpo-39776: Fix race condition where threads created by
PyGILState_Ensure() could get a duplicate id. This affects consumers
of tstate->id like the contextvar caching machinery, which could
return invalid cached objects under heavy
Hi,
tl; dr I'm asking for your permission to merge the following PR :-)
https://github.com/python/cpython/pull/19958
In bpo-40514, I added a new
--with-experimental-isolated-subinterpreters configuration option. I
chose to use a very long option name and to not document it on
purpose: preve
Yes, it can wait until 3.9 branch is created and master becomes the future 3.10.
Victor
Le mer. 6 mai 2020 à 21:40, Brett Cannon a écrit :
>
> Can we wait until after 3.10 development opens up? And could it be a `-X`
> flag?
> ___
> python-committers
ean here. My changes rely on the assumption
that objects are not shared between two interpreters.
I didn't work at all on the inter-interpreter communication.
> On 06/05/2020 6:49 pm, Victor Stinner wrote:
> > It's a practical solution to be able to experiment quickly
> > per
Hi,
Changes on CIs run on GitHub pull requests:
* Travis CI became mandatory
* Azure Pipelines is no longer mandatory
* Please watch Windows x64 job: I would like to make it mandatory in 2 weeks
--
I asked to make Azure Pipelines CI not mandatory on Python PRs since
there were more and more ran
Le mer. 20 mai 2020 à 02:39, Terry Reedy a écrit :
> First, with 2.x really past us, is removing remaining long deprecated
> features, plus some others advocated for removal. I think these are
> best done by the first alpha so that early testers are rewarded with an
> early opportunity to change
Hi,
FYI the Windows x64 CI is now mandatory on Python pull requests (on
the master branch).
Victor
Le ven. 15 mai 2020 à 17:09, Victor Stinner a écrit :
>
> Hi,
>
> Changes on CIs run on GitHub pull requests:
>
> * Travis CI became mandatory
> * Azure Pipelines i
Congratulations Lysandros! It's well deserved, the PEG parser is a
giant beast of complexity. It's good to have someone to take care of
it ;-)
Victor
Le mar. 30 juin 2020 à 21:21, Brett Cannon a écrit :
>
>
> ___
> python-committers mailing list -- py
Le mar. 7 juil. 2020 à 04:21, Raymond Hettinger
a écrit :
> At beta 1, freeze the addition of new features but continue to tweak the
> implementation with code clean-ups, (...)
IMHO clean-ups should stop after beta1. Only the master branch should
receive cleanup changes. A clean-up doesn't bring
FYI this MSDN subscription allowed me to debug tons of Windows
specific issues and to enhance Windows support. It's really very
helpful, at least to me :-) Thanks Microsoft!
Victor
Le jeu. 13 août 2020 à 19:29, Steve Dower a écrit :
>
> Hi all
>
> It seems like people are due to renew their subs
Le jeu. 17 sept. 2020 à 11:57, Łukasz Langa a écrit :
> The 3.9 branch is now accepting changes for 3.9.1. To maximize stability, the
> final release will be cut from the v3.9.0rc2 tag. If you need the release
> manager to cherry-pick any critical fixes, mark issues as release blockers
> and/or
GitHub workflow is nice when a single commit is enough to close an
issue. But what if a bug should be fixed in multiple branches? Is
there a way in GitHub to require one commit per branch to close an
issue?
Victor
Le dim. 11 oct. 2020 à 21:16, Guido van Rossum a écrit :
>
> Once issues move to G
Le lun. 12 oct. 2020 à 08:56, Tal Einat a écrit :
> I've come to think that #2 is especially important. This is a
> difference with a project like ours vs. a work environment: At a
> workplace, there usually isn't a need to thank people for their work
> on an issue, so just making sure that status
I suggest to limit to one "dot" per week, since CodeSpeed (the website
to browse the benchmark results) is somehow limited to 50 dots (it can
display more if you only display a single benchmark).
Previously, it was closer to one "dot" per month which allowed to
display a timeline over 5 years. In
Le mer. 14 oct. 2020 à 17:59, Antoine Pitrou a écrit :
> unpack-sequence is a micro-benchmark. (...)
I suggest removing it.
I removed other similar micro-benchmarks from pyperformance in the
past, since they can easily be misunderstood and misleading. For
curious people, I'm keeping a collection
Hi,
Python has no mandatory Linux CI job on pull requests anymore. Right
now Windows (x64) remains the only mandatory job. Please be careful to
manually check other CI before merging a PR.
--
We had to deal with at least 3 different issues on the Travis CI over
the last 6 months. The latest one
t; with it for a long long time. Long enough maybe for someone to fix the bug!
> Or for someone to replace Travis CI with something less race-condition-y!
>
>
> /arry
>
> On 10/16/20 1:41 AM, Victor Stinner wrote:
>
> Hi,
>
> Python has no mandatory Linux CI job on pull
Hi,
I just gave the bug triage permission to Hai Shi. I will continue to
mentor him for his new responsibilities, as I already did through code
reviews last months.
In 2020, he is the #5 most active developer and the #1 most active
non-core dev developer on the CPython project!
He got 101 commit
Reminder: the deadline for nomination is tonight, hurry up ;-)
Current candidates can be found at:
https://discuss.python.org/c/core-dev/steering-council-nominations/21
Victor
Le mer. 28 oct. 2020 à 20:55, Ewa Jodlowska a écrit :
>
> Hi!
>
> The timeline for this year's election will be the sam
Hi Ethan,
In general, I would say that we don't provide any backward
compatibility warranties on the exact repr() output. In practice, we
attempt to not change it unless there is a good reason for that. IMO
in your case, it's justified. When float repr() was changed, it broke
tons of doctests :-(
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 Nao
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 new_bra
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 w
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
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
discussed.
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 project. 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-
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
>
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 pe
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
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 ther
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 warni
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
Congratulations Irit and welcome aboard!
I hope that PEP 654 "Exception Groups and except*" will be accepted soon ;-)
For the record, link to the vote which lists Irit's work and
endorsement: https://discuss.python.org/t/vote-to-promote-irit-katriel/8457
Victor
On Tue, May 11, 2021 at 7:18 AM B
Hi,
I'm always connected to IRC #python-dev (Freenode) for 10 years, a few
other core devs use it time to time. Come to say hello ;-)
The bugs.python.org and buildbot notifications are useful to me and I
don't feel annoyed by them. But GitHub review are hard to use: only
the user name and the PR
Did you notice that you are already chatting by email? Chatting about
other chat platforms :-) Why not just accepting that emails won? :-)
When discuss.python.org was launched, a few discussions moved there,
and slowly, moved back to python-dev list.
Emails will never die! :-D
Victor
___
Any update on this issue? Nobody recalls what code and service sends a
comment to bugs.python.org when a commit is merged?
Victor
On Wed, May 12, 2021 at 4:23 PM Guido van Rossum wrote:
>
> Recently it seems that when a PR linked to a bpo issue is merged, no note of
> this event is made in the
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 Ku
On Tue, May 18, 2021 at 12:33 AM Zachary Ware wrote:
> I might have found it; I at least opened
> https://github.com/psf/bpo-roundup/pull/1 against what I found :)
Sadly, commits in the main branch are still not logged to bugs.python.org, see:
https://github.com/psf/bpo-roundup/pull/1#issuecommen
I confirm that commits merged in 3.9, 3.10 and main branches are
logged again in bugs.python.org. Thanks to everyone who helped to
solve this issue!
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
python-committers
On Thu, May 27, 2021 at 8:24 PM Pablo Galindo Salgado
wrote:
> > And if a type pointer is the only thing being visited, then there's no
> > point unless the object can itself be reachable from the type object.
>
> But that could happen easily for heap types as they are mutable by default.
> For
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
Acce
See also
https://discuss.python.org/t/remove-coordinator-role-of-inactive-coordinators-on-bugs-python-org/866
for the security of bugs.python.org. So far, no action was taken.
Inactive coordinators kept their permission.
For GitHub, I'm using a Yubikey and FreeOTP for the 2FA.
Victor
On Mon, Ju
Hi Andrew,
If someone ones smtpd, I would suggest to copy it from Python 3.10
(with asyncore and asynchat) and continue the maintenance outside the
CPython Git repository.
Create a project on PyPI if you expect contributions.
Victor
On Wed, Jun 23, 2021 at 9:13 AM Andrew McNamara
wrote:
>
> >I
Hi Irit,
Since it's documented as deprecated, asyncore and asynchat are
deprecated as well since Python 3.6 (smtpd uses asynchat), I suggest
to remove these 3 modules right now. I would prefer to make such
incompatible change early in the development cycle, to give more time
to users to adapt thei
Hi,
If someone sees a random issue on a CI, I suggest to open an issue at
bugs.python.org to track it. Otherwise, slowly, the number of random
failures becomes so high that it takes several "re-run all jobs"
steps, and so merging a basic typo fix takes 1 hour if not longer.
Victor
On Tue, Jun 22
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),
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 e
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 :
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
> approve
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
https://m
Hi Antoine,
You can report miss-islington issues to its GitHub project:
https://github.com/python/miss-islington
I reported two issues:
(*) Backport fails with no explaination, but work if retried (September):
https://github.com/python/miss-islington/issues/389
(*) Approved backport PR not merg
Oh, I confirm that it landed in my Spam folder.
I created a Gmail filter to mark emails coming from
no-re...@mail.heliosvoting.org as "Never send to the spam folder".
Victor
___
python-committers mailing list -- python-committers@python.org
To unsubscri
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
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
> acco
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
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,
test_
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. T
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@pytho
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 archiv
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 when
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 my
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.
(*) https://github.
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 alread
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 Viktorin, Victor Stinner
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
>> 1
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,
> monitors
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, encoding="locale
301 - 400 of 534 matches
Mail list logo
