https://bugzilla.redhat.com/show_bug.cgi?id=2141725
--- Comment #5 from Fabio Valentini decathorpe@gmail.com --- (In reply to Kalev Lember from comment #4)
I don't understand at all what you mean with the pay grade comment. Can you clarify, please?
Sorry, I might have used the wrong idiom here.
I meant to say: The major gtk-rs updates are a bit painful. - it's a lot of packages that need to be built in the correct order - all builds need to be submitted to bodhi together as a single update - not all applications port to new major gtk-rs versions immediately
Especially the last one is the reason why I have, in the past, submitted breaking gtk-rs stack updates only to rawhide (or rawhide and branched, depending on the timing of the release).
I think it's worth trying to make sure there are more than one people who know enough to keep the stack updated. If you don't mind, I'd like to be involved in updating it this time around.
The problem is not the *how*. It's "just work", but it needs to be done carefully, and coordinated with maintainers of affected applications.
What makes it especially complicated? Is there something in the stack that makes it hard to do compat packages to keep apps that haven't been updated for the new version working?
If it's so hard to keep it up to date, maybe we should suggest vendoring it all instead...
The problem is not that it's *hard* to keep it up-to-date and do compat packages, but it's the *scope*.
With previous bumps, usually all but one application had already ported to the new version, so adding a few dozen (!) compat packages just to keep one application building was just not worth it - so I announced the gtk-rs update as a breaking change, and only pushed it to rawhide.
Do you think we'll have more applications that use gtk-rs in Fedora in the Future? Then the effort of creating / building / maintaining a few dozen compat packages for older gtk-rs versions *might* be worth it.