FESCo Meeting Minutes (2015-03-04)
lists at colorremedies.com
Fri Mar 6 20:24:09 UTC 2015
On Fri, Mar 6, 2015 at 11:07 AM, Stephen John Smoogen <smooge at gmail.com> 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
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.
More information about the devel