Alessandro Astone wrote: > But am I supposed to ignore the fact that kkofler is already bullying the > KDE SIG into not breaking that one other package they maintain that > occasionally breaks on kde updates? See example: > https://bodhi.fedoraproject.org/updates/FEDORA-2023-977de87584 To make it clear about the situation of that particular package: The KDE SIG never notifies me in advance about kdepim bumps. They push them to Rawhide, then I eventually get FTI/FTBFS reports for Blogilo filed by some automatic process, and then I scramble to fix Blogilo in Rawhide. If they bothered notifying me, it would probably get fixed sooner. In the particular case I complained about above, they immediately proceeded to build the kdepim update for the current stable release without giving me any time to fix the breakage in Rawhide. The nature of the upstream update was also such that the kdepim libraries removed/moved some APIs upstream, so this was really an incompatible library change, not the usual backwards-compatible change expected within a KDE major release. I am not sure why the upstream kdepim developers opted to make these changes in their KF5 versions, which should really have been in maintenance mode by then, instead of doing them only in the KF6 versions where such changes would have been expected as part of the major version bump. (Hence, my "yet another incompatible kdepim stack update" complaint was also about upstream, not only about the KDE SIG.) The normal Fedora policy for this kind of changes is to give time for maintainers of dependent applications, even if they are legacy applications, to fix the applications before pushing the update to stable releases. In the Blogilo case, I do not remember having agreed to (nor having been ordered by FESCo to accept) anything different. I fixed Blogilo as quickly as I could even though it was not trivial. I am sorry for the few days of delay caused by that. I do not expect the *-x11 updates to take that long, because all I normally need to do there is to bump Version, use the same tarball as for the Wayland version, and rebuild. As long as upstream maintains X11 support, I will not be in a situation like for Blogilo where I have to backport support for changed library APIs to an ancient codebase not updated anymore by upstream. So I do not expect the user experience to be that bad. The one thing that would be helpful is, if I have the *-x11 packages already updated in Rawhide dist-git, to just sync them to the release branch and build them in the side tag when they prepare an update for a release. (As I understand it, the scripts they use to sync branches and build updates can probably do that with no extra human effort.) Though, if not, I can do that too, if only they tell me about the update and the side tag as soon as possible, at least before they hit that "push to stable" button. Kevin Kofler -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
