On Fri, Mar 6, 2015 at 11:07 AM, Stephen John Smoogen <smooge@xxxxxxxxx> wrote: >> Do you acknowledge it's a historical fact that the user password for a >> local device has been exclusively user domain? If no, give >> counterfactual examples. >> > > You need to dial back the dialogue a bit. The original email came across as > an out of control rant that lost me after the third sentence. If instead of > trying to win "Flame of the Day" award and being less metaphorical and more > factual.. it might go a long way to having a conversation versus a man and a > soap box in a park. That the metaphor doesn't work for you is fine. However, while you castigate the method, you ignore the questions seeking out the facts = that which is not in dispute. >> >> You said a product can properly mandate otherwise. Where does the >> authority or sanction come from to do this? Just by saying it is so, >> and then just by doing it? >> >> > > It is a two way street. You own the device. They make the OS. Each is their > own 'ball' if I am using your original metaphor appropriately. Each sees the > other as the field the ball gets played on. If you don't like the field that > your ball is playing on you are free to ask for something to be changed. If > it doesn't get changed you can go find another field to play on. And vice > versa. Your version is not at all the direction I was going in. But I'll go along with your version.... No other field (OS) asserts any concern for what ball (password) I bring. Any ball shape and size is accepted. Suddenly, one field's referee asserts rules that only particular ball sizes and shapes are allowed. The rules aren't actually specified anywhere, I must show the ball and the referee either accepts or rejects it on a pass fail basis. The minimum ball size and acceptable shapes aren't stated in advance. I merely get binary feedback. By iterating, and making some assumptions, I can infer the requirement means I can bring a large box instead of a ball. And after I pass the referee, I can remove my ball from the box and use it on the field. Ergo, I'm simply being harassed. I can't take the referee seriously at all, just appease his demand. Next, the referee asks for a field wide enforcement of his rule that no one clearly understands or agrees with; and none of the field managers (product working groups) even asked for the rule in the first place. > I am not saying this is the best way to handle things, but when everyone > seems that the only way to communicate is jumping up and down on a soap box > claiming the other side is completely in the wrong.. "how to handle things > better" has long been thrown out. Fedora has a rather Socratic mechanism for avoiding this. Twice now, Anaconda hasn't voluntarily submitted to this process on the same issue of password UI behavior. And therefore a heated debate was inevitable in my opinion. Anaconda has made an unasked for and abrupt change without having met a reasonable burden of proof for the claim this is necessary, again this is two for two. Then, as now, in over 100 emails, there are no proponents for the change outside Anaconda. And now, no proponents of the change by any product working groups. Leading a present or future conversation on platform security policy should probably not lead with "we can take your ball away anytime we want." I estimate it's in the vicinity of distinctly unhelpful for positively progressing the conversation. I'm open to suggestions. -- Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
