Do you think this is a security risk and if not is it a bad UI decision?
Bruno Wolff III
bruno at wolff.to
Sat May 4 23:15:16 UTC 2013
On Sat, May 04, 2013 at 15:58:03 -0700,
Dan Mashal <dan.mashal at gmail.com> wrote:
>I would rather have QA have move oversight on these things. As I only
>discovered this while doing QA.
QA isn't really the right place to make up policy. This particular case
doesn't seem to be something that would merit any action by QA unless
the Fedora community developed an over arching possibly on when
passwords can and cannot be displayed.
>Excuse my cynicism here but this would also require some change to the
>QA process itself and what are blockers and what are not and the "nice
>to have" process which should be renamed "we won't hold our breath".
The "Nice to Have" process has been renamed "Freeze Exception", which
better describes what it does.
>So say I did bring this up as a blocker under new criterion like "This
>isn't broken but probably a bad idea criterion" that I think should be
>defined (with a better name) and it was -1'd by the whoever was around
>during the meeting because most of us have $dayjobs, only then would I
>feel it appropriate to bring up to FESCo and then possibly the board.
I don't think this would fly as a QA criterion. QA aren't necessarily
in the best position to decide on whether or not general things
are good or bad ideas.
>I'm not saying it should be on everything. But changes to I guess
>"CRITPATH" packages (which anaconda is one of I think) should be
>vetted in the community not on the anaconda maintainer list first.
I don't think critpath is the right description to use here. I think
where you want to head is the long intended changes to the Feature process.
Though I am not sure this subpart of the anconda UI change would really
rate a Feature all on its own. The Anaconda rewrite is a Feature and
they have been reaching out for feedback.
While I think feedback from the community is nice, I think the
maintainers should generally be making the decisions (rather than voting)
as the maintainers generally will know more about the problem than
random community members.
I also think it is likely that if maintainers start getting overridden by
community vote, we are going to start losing maintainers.
More information about the devel
mailing list