What to do with potential workflow-changing / breaking changes?
Fabian Vogt
fabian at ritter-vogt.de
Tue Feb 21 10:07:13 GMT 2017
Hi,
another openSUSE KDE team member chiming in.
Regarding the consideration of reverting patches, I see the responsibility of
a package maintainer mainly being there to give users the best possible
experience of the applications made by upstreams.
Reverting patches is not an ideal solution, in fact, it is not a solution at
all! A revert is just an preliminary workaround for an issue that needs to be
discussed or fixed in a different way. Same goes for every other patch that is
not completely distro-specific. It is IMO ok to temporarily revert a patch and
start a discussion about it instead of impacting the user directly.
My personal issue with the two patches is simple: Security fixes should not
introduce usability regressions out of proportion in relation to the issue
they fix. Both of the patches do that in my opinion. They fix security issues
in a way that obstructs the user experience. While the underlying reasoning
for the patches is absolutely fine and I'm very glad that someone cares about
security (I do as well, found and reported multiple issues), I doubt that they
would be merged in their current state if it wasn't for security.
For the kscreenlocker patch, the better option would be to just disable the
option to show the password (which is IMO a security issue by itself) again
and the best option to disable pasting. Instead, it did something that breaks
even beyond the screen locker: It erases the clipboard!
That kate/kwrite cannot be run as root anymore is fine for everyone, but the
way the patch implements it is not ok. When run using "kdesu kate" or similar,
the user just gets nothing as feedback! I'm working on a patch to open a
dialog box as the original user but it's not implemented in a readable way
yet.
Cheers,
Fabian
More information about the Distributions
mailing list