Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (dd2f0ea) 38% compared to head (f5102bd) 12%.

@@           Coverage Diff            @@
##           master    #827     +/-   ##
========================================
- Coverage      38%     12%    -27%     
========================================
  Files          88      88             
  Lines       13084   10628   -2456     
  Branches     1830    1331    -499     
========================================
- Hits         5076    1340   -3736     
- Misses       7583    9160   +1577     
+ Partials      425     128    -297     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I'd suggest to squash the commits

at least those related to version removing.

FYI, regarding commit squashing: we've been using squash merges for some time now in this project. Depending on how you want to organize your work the PR-local commit noise may not necessarily matter much.

FYI, regarding commit squashing: we've been using squash merges for some time now in this project. Depending on how you want to organize your work the PR-local commit noise may not necessarily matter much.

You are right, no problem, let's use squash merge.

Yes I agree about the squash merge actually, it's a bit easier for the contributors.

@temoto, @jstasiak: Even if I'm now an eventlet orga team member, I'm not able to merge patches from the eventlet repo. I think you need to tweak some specific rights of this repo.

However, in a first time I'll only focus on easy patches like this one, to become more familiar with the eventlet repo and avoid mistake.

@temoto, @jstasiak: Even if I'm now an eventlet orga team member, I'm not able to merge patches from the eventlet repo.

I think that's because you were in maintainers but not in develoepers. I just added you to the developers team, try now.

@temoto, @jstasiak: Even if I'm now an eventlet orga team member, I'm not able to merge patches from the eventlet repo.

I think that's because you were in maintainers but not in develoepers. I just added you to the developers team, try now.

Looks better, thanks.

@itamarst: However, we should notice that the merge is still disabled due to the required tests that are failing, so what do you think of my development branch proposal made there?

Using this development branch we could temporarly disable failing tests, then redirect this pull request and your other one (#823) against the development branch rather than against the master branch, then, merge them, and finally re-enabling all the tests.

That would avoid disabling the tests, on all the master pull requests. Even if they tests are not functional, they protect us from merging patches accidentally. Patches merged on development could be later cherry-picked to master.

@jstasiak: I think the same admin action should be done for all the persons recently added. Big thanks for your time and for your help!

Everyone else was already in the developers team so I don't think anything to do there. Let me know if it turns out otherwise though.

FYI for your convenience I temporarily disabled the requirement for PRs to have green builds to be merged. Let me know if you want it undone (and when).

Everyone else was already in the developers team so I don't think anything to do there. Let me know if it turns out otherwise though.

FYI for your convenience I temporarily disabled the requirement for PRs to have green builds to be merged. Let me know if you want it undone (and when).

Great, thanks

@itamarst: which pull request are you desire to be merged first?:

• this one
• Try to make CI pass tests #823

My plan is:

1. Merge this one.
2. Split the "green CI" into two, with initial PR only covering 3.8-3.10, since 3.11 is the most significant change and 3.11 is moreover not even in current CI config.
3. Do a third PR that adds 3.11 support so it's easier to discuss in isolation.

I took a look at recent download stats from https://pypistats.org/packages/eventlet (and used its API to get raw stats so I could compute monthly aggregates) -- I worry that dropping 3.7 may have been a little hasty. While 3.7 downloads have been trending down for months, we've only just this month begun getting more downloads from 3.7 than 3.11; 3.7 accounts for roughly one in eight downloads.

Honestly, I'm not sure why there would be so many 3.7 downloads; my recollection was that Ubuntu LTS releases used 2.7, 3.8, 3.10, while RHEL/CentOS hit 2.7, 3.6, 3.9... DistroWatch gives me a hint that it may be Debian Buster? If so, at least their long term support would end come the middle of next year...

The question seems particularly important, though, given the premise of eventlet as critical to whole ecosystems of projects and our need to address security issues.

@thomasgoirand o/ Any opinion about the previous comment?

I opened a new issue for the 3.7 discussion: #846