Hi Michael, Michael Stone: > FWIW, I also think apparmor a bad idea,
For me it's good news: if you explain why (please?), it will furnish nutrient to this discussion and we'll be in a better position to make the best decision we can for our users and free software :) > but it's somehow morphed from "can we make it possible to turn > apparmor on" to "let's make RC bugs for stuff that doesn't work with > apparmor" without much real buy-in AFAICT. Regarding "can we make it possible to turn apparmor on": this has been possible for years and was announced on d-d-a@ 2.5 years ago. This is *not* what the proposal I've sent in August was about: that one was explicitly about enabling AppArmor by default. If you're suggesting there's been a decision making process mishap, then I'll need to be explained why, because I don't get it. Regarding "without much real buy-in": even though I believe we've reached consensus on my proposal between August and October (as Ian Jackson explained last week on this mailing list), I agree with you on this one. This proposal did not trigger an overwhelming wave of enthusiastic support. We don't make decisions by public acclamation here but still, it's an important data point and IMO it implicitly raises the bar wrt. how good our AppArmor support must be in order to be acceptable by the project. Regarding RC bugs: I don't think breakage that only happens with AppArmor enabled should be RC in the context of the experiment we're currently running: in the vast majority of cases, a local workaround is available (one can disable the faulty AppArmor profile with the aa-disable command). If we decide to leave AppArmor enabled by default in Buster we should reconsider this though. Regardless of bug severity, I want to keep fixing these bugs. If you need help with AppArmor-related issues, you can ensure they're on pkg-apparmor-team's radar this way: https://wiki.debian.org/AppArmor/Reportbug#Usertags Cheers, -- intrigeri
