On Mon, 27 Jul 2015, Kevin Fenzi wrote:
On Mon, 27 Jul 2015 01:19:55 -0500 (CDT)
Michael Hennebry <hennebry@xxxxxxxxxxxxxxxxxxxxx> wrote:
There is more than a draft.
There is code that is annoying people, hence this thread.
The suggested change that suppsedly is not here
yet is to have a uniform password-quality standard.
The password setting "request" as part of an install
is different from all other password settings.
It comes before the user has been able to customize the system.
Any quality standard that is part of an install should be advisory
only, regardless of any otherwise uniform standard.
Whether others are advisory should be customizeable.
The above is stuff thats all being worked on, yelling at anyone is
unlikely to change the speed at which it gets done.
What does "worked on" mean?
It seem to me that that is precisely the issue.
It could mean fixing the problem.
It could mean setting it in stone.
My expectation, and I think that of others,
is that for anaconda, it will be set in stone.
Does the password standard for install-time
passwords currently come from anaconda?
If so, heaping comments on the anaconda people is the thing to do.
If not, the comment heap should go elsewhere.
In neither case do I see the point of patience.
Patience is likely to give the people that
matter a false sense of approval or tolerance.
You're of course welcome to do whatever you like, but in my experience
Open source maintainers treat impatient / intolerant people either by
Patience and impatience are not completely complementary.
They both refer to behavior that is in some sense an outlier.
( consciously or unconsciously ) ignoring them ("I have 50 bug reports
from patient / tolerant people to look at") and/or
by even becoming more determined to not make the change suggested by
such people ("If I make this change it might make people think we
respond to impatient / intolerant people").
How is a maintainer or a standard writer suppose to distinguish
patience-based silence from approval-based silence?
Is there currently any reason to suppose that from now on
anaconda will not enforce its notion of strong passwords?
In case the current work includes the setting in
stone of anaconda's demand for "strong" passwords,
what can or should those who prefer
encouragement to enforcement do about it?
--
Michael hennebry@xxxxxxxxxxxxxxxxxxxxx
"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
