Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document CPython lifecycle periods of reduced core dev capacity #937

Closed
arhadthedev opened this issue Aug 18, 2022 · 2 comments
Closed

Document CPython lifecycle periods of reduced core dev capacity #937

arhadthedev opened this issue Aug 18, 2022 · 2 comments

Comments

@arhadthedev
Copy link
Member

As one of the core developers commented:

We are currently busy with 3.11 release. It may take until 3.11.0 final before we come back to this patch.

Hovewer, seeing no publicly visible increase in CPython PRs, I had no idea that the pre-release period (few last betas and all release candidates?) is loaded. Only after becoming aware of current priorities I've got the idea that monthly massive bumping of all my PRs is counterproductive and just reduces the capacity even further.

I believe that such annual hot periods of Python lifetime should be documented in, for example, Lifecycle of a Pull Request section of the devguide. Probably, it can be published as a mapping of day&month spans to relevant affairs.

@terryjreedy
Copy link
Member

I believe the 'we' in Heimes' comment referred pretty specifically to himself and G. Smith. Your PR is not labelled as 'bugfix' or 'feature'. Some devs focus on bugfixes during the beta period. Some devs (including me) are focusing on doc fixes during this first candidate period as that is what can be merged most easily. Others on final critical bugfixes. Others seem to be on 'vacation'. The devguide could point to the annual version cycle as having some effect on dev time, but it is hard to generalize across all of us.

@ezio-melotti
Copy link
Member

This will also need to be maintained and updated, and someone will have to link it from issues/PRs (possibly as a canned response), since it seems unlikely that contributors will go looking for it in the devguide. As Terry mentioned, we could point to the annual version cycle, but if contributors are not going to see the pointer then it's kind of moot doing it.

I suggest closing this issue as not planned.

@ezio-melotti ezio-melotti closed this as not planned Won't fix, can't repro, duplicate, stale Aug 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants