--- Comment #2 from Pedro V <> ---
(In reply to Harald Sitter from comment #1)
> What exactly do you want to happen here?

Assuming that there's an implicit understanding of what the problem with
inquiry about expected resolution, I see the first step being someone with
authority deciding how this long standing problem is supposed to be handled
instead of just letting user experience suffer, and keeping around bug reports
where the issue is clearly understood, there's just no plan to do anything
about the problem.

Not necessarily an exhaustive list of possible decisions, but I can see one of
the following paths being chosen:
- The whole problem is decided not to be on KDE, considering libssh issues not
to be relevant here despite them impacting KDE user experience. In that case
the relevant issues should be closed as not planned to be resolved here.
- Depending on libssh might be still desired, but it either gets forked so
issues can be patched bypassing upstream issues, or part of the functionality
like known_hosts handling gets replaced with code not using libssh.
- Deciding that libssh is not sufficient, so replacing it with another library
or a new implementation (not really seeing this happening, but still a

Take this as more of a pushing for decision with possibly cleanup effort.
Ideally a task would be made outlining the chosen plan of resolving the
problem, and all related bug reports could be closed as a duplicate of that.
Even if there would be no fix any soon, it could at least centralize all the
different bug reports into a larger "libssh limitations" topic, so users could
be pointed there instead of letting each bug reporter individually discover
looking at yet another manifestation of SSH config options just simply being
ignored instead of KDE having some really weird bug.

You are receiving this mail because:
You are watching all bug changes.

Reply via email to