Gregory's Server@juliank @tuxwise @keepassxc You work for a company that maintains a distro on which you are a core developer. That is relevant, especially because it makes it harder to hold you accountable for your bad actions: people might feel threatened by the power of your employer in the open-source world and let you get away with bad actions that others would not get away with.
And while it may be quite normal for a German to insult other people, it is quite normal for an American to say someone who does a bad job should be fired. Respect for culture must go both ways!
(though all the Germans I am friends with are generally quite nice people who do not go around insulting others, so perhaps it is not something you can blame on culture)
And if you are saying "there's no going backβ, that means you are not open to discussion or to having arguments presented which would change your mind or change your actions. This should disqualify you from a position where you make decisions that impact other people.
You are a distro maintainer. You can decide to package something or not to package it. You should not decide to package something and also effectively fork it in the distro package because you do not like the choices the developers made. If you disagree with their choices, go to them and present your arguments and try to convince them to change. If you do not convince them, you can always perform a real fork and promote your fork.
Above all, what you should NEVER do is abuse your position as a distro maintainer and employee of a distro company to force your preferences onto someone elseβs project against their will. But that is exactly what you did. If you called your package βJulian's KeePassXC Forkβ and lobbied to have Debian include it, that would not be a problem. But you call your package KeePassXC and prevent the real KeePassXC from being allowed into Debian, just because you prefer to make people use Julian's KeePassXC Fork. That is a problem.
And, again, features like checking against databases of compromised passwords are strongly recommended best practices. See, for example, section 5.1.1.2 here:
https://pages.nist.gov/800-63-3/sp800-63b.html
I direct you again to my previous post suggesting what actions you should take.
@ubernostrum you seem to mistake there's no going back for something it isn't but it means the situation was untenable.
I do not have a problem offering an explicit choice between a keepassxc-minimal and a keepassxc-full package.
Anyway, right now, keepassxc packages the default build flags, and keepassxc-full passes the option to turn additional features on. We're not at the outrageous territory where we need to take defensive measures by patching code, yet anyway.
@tuxwise @keepassxc