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