Topic on User talk:AntiCompositeNumber/Flow

If I understood correctly you said in phab:T283083 [Session] RFC: Re-evaluate librsvg as SVG renderer on Wikimedia wikis , that phab:T40010 RFC: Re-evaluate librsvg as SVG renderer on Wikimedia wikis is stuck by phab:T216815 Upgrade Thumbor to Buster, which is planed for this summer and might delay depending on the thumbor-responsible person User:GDubuc_(WMF), who is very busy because he is also in the Wikimedia Performance Team. (However I do not understand how postponing reduces work?)

However regarding my memory about your statement I have two questions:

1. According to the Debian-release-table, the end of Security-support ended June2018 (3years ago), and the end of long-term-supports will end June2022 (one year ahead). Is there a different Wikipedia-update-circle?
2. Why does phab:T40010 RFC: Re-evaluate librsvg as SVG renderer on Wikimedia wikis depend on phab:T216815 Upgrade Thumbor to Buster? resvg is portable, so it is independent on the thumbor-server-version, so I see no reason to wait on the thumbor-update.

The rough guideline is wikitech:Operating_system_upgrade_policy. That document hasn't been fully implemented, but my understanding is that most teams were working toward the June 2021 target (progress tracked in phab:T247045). Changing the SVG renderer isn't blocked on the OS upgrade in the traditional sense, rather it is a question of development priorities. Potentially changing the SVG renderer is a lower priority than the OS upgrade. Changing the Thumbor dependencies while someone else is working on OS upgrades could complicate the upgrade process and duplicate work. Because I don't have good visibility into how the upgrade work is proceeding, I would be reluctant to make changes to Thumbor to implement an SVG renderer change at this time.