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