Let’s start planning the 2020 Core Dev Sprint! Some things to consider:
Date: Last few years we’ve been having it the second full week of September. Do we want to keep the same timeframe or change it to October/November?
Location: In 2019 it was in the UK, we should consider a different region this year. This also ties into which organization can help host/sponsor* the event. Is anyone aware of other organizations wanting to host/sponsor?
*Hosting involves providing space for 40+ core developers, breakfast, and lunch daily for 5 days. It is ideal if the organization can also help the PSF fund some of the travel/hotel costs in addition. Additionally, there should be a core dev involved to help with the RSVP process and work on creating the schedule.
If folks have any thoughts, comment here or email me.
Ewa started this thread in response to me piping up as looking to have Google host the sprint this autumn. I’m following up on everything needed to make that happen internally (local managers supportive, likely feasible, but nothing guaranteed at the moment).
It’d likely be in Sunnyvale, California as that is where I and most of our Python and other languages teams are based.
As far as dates go, I suggest maybe October or early November as that is half way between PyCon 2020 and 2021 and avoids some potential non-python related plans I have mid September.
Looking at the PEP-596 release calendar, 3.9 will be squarely in bugfix-only and release mode this autumn regardless of which date we choose.
Others with venues should also feel free to also propose hosting arrangements.
I’m trying not to miss Canadian thanksgiving with my family for second year in a row, (Monday Oct 12) but otherwise any time October/nov is fine. September is ok too. Thanks.
Usually, tons of new features land during the core dev sprint. Some sprints were disaster in term of short term stability: new features means “tons of large changes” merged in a short time. Each change comes with its bag of tiny regressions.
Since PEP 602 (Annual Release Cycle for Python), I’m no longer sure how we should synchronize the sprint with the release. Is it better to land new features at the beginning of a new release, or just before the feature freeze? I guess that a reasonable release manager would prefer the beginning of a dev cycle: so after 3.9 feature freeze for example.
In term of communications, it might be interesting to “launch” a new dev cycle by merging new features. It makes the future release more attractive. Anyway, users would only have to wait for 12 months to get them in the worst case, thanks to PEP 602
The other side that if we add attractive features to 3.10 while 3.9 is being stabilized, 3.9 may look less attractive…
A compromise may be to organize the sprint after 3.9.0 release to really “launch” the 3.10 dev cycle (even if technically, it started at the first 3.9.0 beta). So after “3.9.0 final: Monday, 2020-10-05”. Sometime between October 2020 and May 2021?
Some core devs like to fix bugs during the core dev sprints, but in my experience, most core devs prefer to push features. Bugs can be fixed anytime, there is less need to organize a physical meeting for that. Features require discussions and coordination: physical meetings are great for that!
I wouldn’t discount the usefulness of physical meetings when bugfixing (and in particular figuring out bugs) I do agree that right after 3.9.0 is probably better than right before it.
Kicking off new features is the best benefit of the in-person time. Those of us who just burn through bugs generally don’t have any useful features to work on for whatever stage we’re at while the sprint is on.
Didn’t PEP 602 have a section on scheduling sprints? I know the other two did. If a schedule was considered, discussed and accepted, then we already have an answer to the question
“creates a predictable calendar for releases where the final release is always in October (so after the annual core sprint), and the beta phase starts in late May (so after PyCon US sprints), which is especially important for core developers who need to plan to include Python involvement in their calendar;”
It gives us some direction but nothing concrete - at least that’s how I read it
October 19-23 looks pretty good to me. Y’all could stay in town and catch my gig in Cupertino on Saturday 10/24
If Google can’t do it, I can definitely look into LinkedIn hosting. We’re also in Sunnyvale. I’m pretty sure I could find space and funding for 40-ish devs.
We’ve got an appropriate meeting space reserved. I still need to follow up to see if I can get any of our orgs to kick in some money to help cover people’s costs.
As I expect people expect: We’re in “no Events” mode until further notice. Intentionally non-specific, but it seems realistic to me to plan for this to mean it will be 18 months until international and domestic travel population mixing events can be held again. Anywhere in the world.
I’m still down for hosting our next physical Core Dev Sprint at Google. But I don’t expect that to make sense anywhere until after the pandemic is over.
We should experiment to figure out what could make good virtual timezone coordinated sprinting sessions and do a couple of those this year. That topic deserves its own thread.
I’m following up on everything needed to make that happen internally (local managers supportive, likely feasible, but nothing guaranteed at the moment).