On 18. 01. 22 21:22, Paul Wouters wrote:
I screwed up python-async-timeout in Fedora 34 by pushing it from 3.x to 4.x.
I should not have bumped the major without significant more testing and
talking to people. I rushed it through and caused lots of breakage.
So first, I really do want to apologise for the mess I caused. And I'll
make sure it won't happen again.
Thanks for saying this. We all screwed up something at some point.
It seems the update received negative karma in Fedora 35 -- when that happened,
you should have immediately disabled autopush to Fedora 34. (I am not saying
this to rub your nose in it, but rather as an advice for future-you and for
others as well.)
The biggest issues is breaking python-aiohttp. I've spend some
looking at bumping python-aiohttp to 3.8.x to match it up with
python-async-timeout 4, but both the python-aiohttp test cases fail as
well as my own $dayjob code using it.
There are a four more (known) packages that fail based on the API change
that could probably be fixed, but there would also be other python code
outside fedora that might fail on the API change. And since my attempted
use of the newer version of python-aiohttp in fedora 34 is also causing
issues, I think the safer choice is to roll back python-async-timeout
from 4.x to 3.x using Epoch.
I do think undoing python-async-timeout with an Epoch is ugly but the
best path forward. I think due to the pythondist specific requires, we
would not need to carry the epoch into f35 or rawhide to preserve EVR?
No, I don't think we need to carry the epoch to F35 and rawhide. Distro
upgrades happens with distro-sync.
I am looking for some guidance to ensure I don't break things
and I apologise for the extra work that I have and am causing everyone.
My guidance: Open a Pull Request with the revert+epoch and share the link here.