Misunderstanding with mentiners of KDE projects.

Almost every time I come across KDE project mentiners (3 of 4), I run into … let’s call it a misunderstanding.

First (long before the removal of qt4 from Factory), I fixed the broken package (I don’t remember exactly, it was either qtcurve or some kind of plasmoid) and sent SR, to which the maintainer refused to accept it with words, I would rather accept request to remove this package than to accept this SR. It was already a piece of fat, but I put up with it.

Then they did not want to consider it a bug that the spectacle did not start without QML_DISABLE_DISK_CACHE=1 if /var/tmp was mounted with the -noexec flag. It wasn’t about eliminating it, but simply classifying it. Well, here it was partly possible to understand that by default /var/tmp is not mounted separately, although you need to use the /run directory to start any jit compilation, but there should not be any executable files in /tmp or /var/tmp.

And now, when I wanted to fix the soundkonverter package and send it to the Factory (the only package from KDE:Extra which is not in Factory and which I need), the mentainer refuses to do this simply because the package is not supported upstream, while with the package itself everything is good. I thought the maintainer didn’t want to mess with it and I volunteered to be the maintainer of this package. to take over his support, to which he was refused with the reason that this package does not need support and my help is not needed. And then he writes that he spent a lot of time maintaining qt4, which was unaccompanied by upstream and now will not accept any package without upstream support. That’s how I understood him, here is our correspondence.

However, I think his position is inadequate!

1 soundconverter has nothing to do with qt4 and no package depends on it! Comparing it with qt4 is simply inappropriate!
2 He refused my help with an maintain, saying he doesn’t need her.
3 There are many projects in Factory without upstream support, for example opendkim, without which a modern mail server will not work, or libcaca, which is generally in Ring1 and whose mentiner I am, wol (Wake on Lan), and so on. Downstream exists for this.
4 With the package, at the moment everything is in order, apart from the little things that my previous SR did, and will finally fix this SR. There are no legal issues, no build issues, instability or security issues.
5 At the moment, I believe that there are no alternatives to it. There is a soundconverter package for Gnome, but it is inferior in capabilities, and it is written in GTK3/Python3/Gsteamer, which is unacceptable for me to a package in Qt/C++/ffmpeg.

I do not like. that I have to put it out in public, but I have no other choice. It’s not that I was denied SR and I’m complaining. My SRs were rejected in other projects as well. but it was convincingly substantiated and I understood their position, which made sense and either corrected the comments if it was possible and sent the SR again, or retreated if it was impossible. And here. from my point of view, just inappropriate behavior of the project maintainer.

What should I do in such cases to ordinary mortal members of the community, which I am, who do not work in suse and who have no other way to influence this, given that it did not work out to agree?

I don’t know. is it possible to add this package to another project, for example multimedia:apps, and send a request to the Factory from anywhere, but I really would not want to lead to this. This will be a sign of that. that the openSUSE community is turning into Debian, where every maintainer is pushing his line without paying attention to anyone.

Without wanting to get involved in any situation,

From your description,
It does sound like you have some options you may not have explored…

  1. Submit your changes upstream. I don’t know how radical your code is compared to what you’re replacing, but you can always make your contribution a KDE decision and not an openSUSE maintainer decision.
  2. You can always fork your contribution instead of outright replacing the original package. Write up a good description and document so that people know what you’ve created. Then you can decide where you can find a home for it… My guess is that it’d still be preferable to be part of the upstream KDE Qt packages, but even if it stays as a private repo on OBS, it can be found with a package search (again, assuming you do a good job with description) and your package name).

Stay optimistic.
If your code is good and solves a problem, if others run into the same problem they may find your package and try it out… and if the word gets around that your code solves a problem you’ll see backing from others.