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