Page Comparison

...

Item	Presenter	Notes
Deprecating support in repos that don’t have maintainers.		eg. Dropping node 18 support in repos that are not critical and not maintained so that future maintainers can just do the work without having to wait 6-months after This almost sounds like expectations for maintained or unmaintained repos rather than a DEPR issue. But if a repo transitions from unmaintained to maintained, does the new maintainer need to do 6-month warnings for dropping old support. Once all maintained repos have dropped support for something (post 6-month window), it is fair game to drop support in any unmaintained repo.
6-month support window for simultaneous python versions doesn’t seem prudent		Bumped to next time.
Teak Maintenance Goals, take a look at https://docs.google.com/spreadsheets/d/1wtpoypH1XOPc_G6h9AUNXJ6XiNKD6dlkMP3lubdpE9I/edit?gid=195838733#gid=195838733		Bumped to next time.
edx-platform specific topics below
Ubuntu 20.04 vs ubuntu-latest		Makes a lot of sense for libraries but maybe we don’t do this for IDAs We should pilot with latest and see how it goes but if it causes a lot of churn we can go back to pinning. Is there a way to know which repos are using c-extension that core python uses.

✅ Action items

Brian Smith will update the DEPR pilot issue with the exception for unmaintained repos. Something like “Once all maintained repos have dropped support for something (post 6-month window), it is fair game to drop support in any unmaintained repo.” but with examples of when this notification happens.
Next Time: Continued discussion on whether we should change the Depr 6-month window approach. Should we have one big ticket for something like Python 3.8 or Node 18 and just start the 6-month clock once all the maintained repos have been updated?
Feanil Patel ticket enabling cron CI of master every week so we know when external changes might have broken some repos that are usually not getting updates.

...