We discussed this during the FESCo meeting today, but didn't reach a conclusion.

+1 from me.

+1 here.

The most drastic change of this update IMHO has already been backported to rawhide and it has broken a lot of things. I'd appreciate if fixing them was part of this change proposal.

The change vaguely speaks about this:

Scope: Proposal owners: help Python binding users adjust to the string change
Other developers: Fix Python 3 string/bytes usages in API users
Dependencies: The Python 3 string change has impact on several packages but this is already in process

I wonder at what point is this considered done, what part of this will be done by the change owners if the package maintainers won't fix their packages prior to F31 freeze (beta and final).

Also, I don't like the contingency plan much:

Contingency mechanism: Roll back to rpm 4.14, but under no circumstances should such a thing be necessary.

Under no circumstances means there is no criteria for breakage. That means no contingency plan exists.

I'm OK with going to the new version, but I would like the change page to address the things that @churchyard pointed out above before voting.

Contingency mechanism: Roll back to rpm 4.14, but under no circumstances should such a thing be necessary.

Under no circumstances means there is no criteria for breakage. That means no contingency plan exists.

That's not at all what this means. It just means that there is nothing we can foresee from the current point in time that should make this necessary. If something pops up we can go back to the previous version.

+1

The most drastic change of this update IMHO has already been backported to rawhide and it has broken a lot of things. I'd appreciate if fixing them was part of this change proposal.
The change vaguely speaks about this:

Scope: Proposal owners: help Python binding users adjust to the string change
Other developers: Fix Python 3 string/bytes usages in API users
Dependencies: The Python 3 string change has impact on several packages but this is already in process

I wonder at what point is this considered done, what part of this will be done by the change owners if the package maintainers won't fix their packages prior to F31 freeze (beta and final).

On the 4.15 rebase, the compatibility hacks currently in rawhide will be dropped and that's it. We gave two months of head start on this by porting it to rawhide and filing bugs on dependent packages, some have been fixed while others have not reacted at all.

The change owners will ensure that the distro release will not be blocked by this and help anybody seeking help on the subject, but beyond that I don't see how it's unlike any other API change, where individual package maintainers are expected to keep their stuff working or risk getting removed from the distro (although clearly software can stay in Fedora for years in an entirely dysfunctional state).

Also, I don't like the contingency plan much:

Contingency mechanism: Roll back to rpm 4.14, but under no circumstances should such a thing be necessary.

Under no circumstances means there is no criteria for breakage. That means no contingency plan exists.

Oh come on.

Like @ffesti said, it simply means that we cannot even imagine a scenario where going back would be necessary because there aren't any radical changes that would destabilize things to a point where we can't easily fix it in the new version. This is not a radical rewrite or replacement of a central system component, it's just your average evolutionary rpm update, tenth of its kind on my watch. Not once have we been anywhere near having to go back to an older version, and this is not expected to be any different, and that confidence is what the extra remark on the contingency mechanism was supposed to convey (but apparently failed).

Can we please make 1631292 public OR remove it from the discussion here? I don't think we FESCo discussions and decisisons should be based on RH-private bugs.

Oh, sorry! It was never meant to point to a RHEL bug but to its Fedora counterpart: https://bugzilla.redhat.com/show_bug.cgi?id=1693751

Page updated now, thanks for pointing this out!

1693751 is annoying, but bugs happen. I think the rpm maintainers have done the right steps by filing issues against all packages. The changes that need to be done are quite simple, and the onus is on the maintainers of those packages to push them through. RPM 4.15 brings a lot of new functionality that we need to push other things in Fedora. We should try to push the necessary updates to other packages as quickly as possible and get on with the RPM update.

I think the rpm maintainers have done the right steps by filing issues against all packages.

Minor correction, we didn't actually file issues to all rpm-python dependent packages, only those that seemed affected based on a brief source-code analysis. Turns out I missed at least a couple of packages that were broken by this, so in retrospective we probably should've filed aganst all. Oh well.

Yes, this is merely an API change. However I don't consider the "deprecation" period long enough and the communication about that satisfying. I was bit by this change in 2 projects (Fedora-Review, compose-utils) and neither of them had any Bugzilla filed by rpm maintainers.

before this change, there was no announcement about the deprecation. This is the first "public" announcement and you already talk about removing the compatibility hacks, while the forward compatibility flags in previous version s are not yet designed.

Does this change make Fedora worse for the users? No, it does not.

Does this change make Fedora worse for the contributors? Yes, it does, at least until we manage to fix rpmlint and other dependent projects heavily used by our packager community.

I also don't agree that "the changes that need to be done are quite simple", see for example this Fedora Review "fix":

https://pagure.io/FedoraReview/pull-request/360

Yes, the changes that are needed to make it work with the new rpm are trivial. To make it work with both is tedious. And while I was always against the "common spec" movement, I am very much in favor of "common upstream" - we cannot expect all upstreams to maintain 2 branches of the software, forever (or at least for a year if we ignore EL).

The compatibility hacks appear to be hurting more than helping, and were always intended as a temporary (not the permanent kind) crutch to help getting past some initial bumps.

Packagers have the choice of patching just rawhide initially, and deal with upstream and other things later once the overall situation clears up. Many projects still are compatible with python 2 and those generally are compatible as-is, the only problem is the python3-only projects who had adapted to the broken python3 api of rpm, instead of complaining and filing bugs to get it fixed (although I blame the python3-brainwashing more than the maintainers for that)

No, it's not particularly nice, it's just something we need to get done and over with. Like said, we'll be happy to help porting anybody seeking help.

(In case it's not clear I'm not saying let's not do this, I'm just arguing that fixing severe parts of the packaging ecosystem should be considered as a goal of this change and not left hanging.)

As I said earlier:

The change owners will ensure that the distro release will not be blocked by this and help anybody seeking help on the subject,

If the packaging toolchain is not a release blocker then that's a bug in something else.

This was discussed during today's FESCo meeting:
AGREED: Change is accepted (+6, 1, -0)
ACTION: mhroncok to put a I've told you so note in the top drawer