That update seems to be against the update guidelines, changing python2→3 in F29 at this point. The update will not be unpushed, because it already went stable. To undo the change, the package should be rebuilt with python2 and a new update created. If it is not possible to build current version with python2, the epoch must be bumped and the older version built again.

Removing Python 2 subpackages is indeed forbidden as mentioned in the ]Python guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_multiple_python_runtimes).

I also agree that this goes against the updates policy.

Yet I don't really think it needs to be handled at FESCo level (yet) unless one of the following happens:

• either @psss won't respond - in that case, you can start the nonresponsive maintainer procedure
• or @psss says they disagree - in that case FESCo should probably intervene

At this point, it just looks like a maintainer who hasn't realized that their update is disruptive - this happens all the time.

I encourage you to try to talk to @psss about this. I encourage you to use the updates-testing repo to be able to provide feedback to updates before they hit stable. I encourage you to give @psss the benefit of the doubt and use a more friendly language in the bugzilla where you reported the problem.

I am sorry that this problem hit you.

Sorry for the tone, but I'm getting pretty frustrated. My job is blocked (it is not only 'did') since I've updated to F31 (i.e. early September as I've tested pre-release) and I have to do nasty workarounds to get things done. Now I see that it is not only me, the brave early adopter, but also colleagues who stay with obsolete... er... I mean stable versions and still get their tooling broken.

The other bug hasn't been touched for over a week - I know, a week is nothing if we're not talking about serious security issues, I myself am guilty of letting some bugs filed on me to rot. However, still I'd perceive it a bit different if this is first update after 11 months, during which time two new distro versions were released, while it broke with the first one. And more importantly, we were explicitly asked to test the update, so I'd really expect the problems reported are not in vain (to be ignored for the next 11 months).

Given the timeframe that F29 should get EOLed in 15 days, if I'm not mistaken, I'm not sure if there is enough time to test maintainer's responsiveness and do the rebuilds.

But that's upon you to decide, I just wanted to move with that somehow, for the abovementioned reasons. Thankyou for your time, whatever the final resolution will be - I've tried ...

Note that if there was an easy action to do (unpush), we would have helped. However as @zbyszek says, it's too late for that. A revert is needed instead. And while we certainly can rubber stamp that, FESCo cannot make anybody do anything. If there is a pull request you want us to force-merge-build-push, we can help, but we cannot change the past.

Do you want us to take a vote on whether the update was against the rules and should be reverted?

I'm not familiar with the package and I'm no Python expert, so I don't feel like preparing update. All I could do would be just reverting to selected previous git commit and increasing the epoch as suggested. Guess that can be done by anyone if you vote for revert ... I don't know the processes (so, sorry for being naive that there is some "unpush" button somewhere for those in power ;-)), please do whatever you deem appropriate.

I agree with what Miro said before: we should first assume that this was just a simple mistake. This should be handled first in the bug. Let's close the ticket here. If it turns out that the normal channels don't work, we can revisit.

Thanks for letting me know about the problem. I haven't seen the bug because of too many emails coming to my inbox. Karel, if you need to escalate a similar issue, please ping me on irc or send me a direct email which will not be catched by email filters.

Regarding the update itself: My estimation was that vast majority of did users are using it right from the command line so updating from Python 2 to Python 3 should not affect user experience at all. Haven't realized that for Fedora 29 it's not a good idea. Will be more careful in the future.

As far as the internal plugins are concerned, I gave an early heads-up to the team to test with the new version and as far as I know the necessary changes have been already done so it should work fine again. We need to move everything to Python 3 anyway.

I'm ok with reverting the change for Fedora 29 but I'm not sure it's worth it as today I've also fixed regression in BZ#1768371. Let's discuss the best solution in BZ#1770765. Thanks.