Drop older Python versions

[itamarst]

Fixes #819
Fixes #822

Tests won't pass for now, but should at least run as before, just fewer builders.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

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

Additional details and impacted files

@@           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     

Flag	Coverage Δ
ipv6	12% <ø> (ø)
py36epolls	?

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[4383]

I'd suggest to squash the commits

[4383]

at least those related to version removing.

[jstasiak]

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.

[4383]

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.

[damani42]

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

[4383]

LGTM

[4383]

Not sure why the deps of below testenv manage Python 3.11 and why the above envlist, apparently, not. As the semantic of these changes is to drop EOLed Python releases, this patch LGTM.

[4383]

@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.

[jstasiak]

@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.

[4383]

@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.

[4383]

@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!

[jstasiak]

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).

[4383]

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

[4383]

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

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

[itamarst]

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.

[tipabu]

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.

Python Version	July	August	September	October	November
2.7	34613	34128	31711	32852	36821
3.4	91	101	39	42	49
3.5	1035	534	655	640	758
3.6	61010	52010	45942	50901	53917
3.7	335613	303073	255596	220816	194961
3.8	311678	244907	277575	349432	341839
3.9	180688	223139	194558	175212	172666
3.10	519239	465097	294619	263098	242695
3.11	69017	75176	69583	77139	184093
3.12	84	269	317	4062	5773

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.

[4383]

@thomasgoirand o/ Any opinion about the previous comment?

[itamarst]

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